Status Page Examples

What this status page should answer

Examples are useful when they show how real services group customer-facing components. Look for clear names, few internal dependencies, and a layout users can scan while support volume is already rising.

• Strong examples use a handful of recognizable component names.
• They keep internal dependencies off the public view.
• They stay scannable under the load of an active incident.

What separates a good status page from a bad one

The best status pages share a pattern: a short list of components named in customer language, each backed by a real check, laid out so a worried user gets a yes/no answer in seconds. Weak status pages fail in predictable ways — they list dozens of internal services nobody outside the company recognizes, they mix current status with a running log of engineering notes, or they are updated by hand and lag reality. When you study an example, ask one question: could a non-technical customer, mid-incident, tell in a glance whether the thing they use is working? If yes, it is worth copying; if not, it is a cautionary tale.

• Few components, named the way customers refer to them.
• Each component backed by a live check, not a manual toggle.
• Current status kept separate from the incident narrative.

Building the page in Sandglass

Model your Sandglass status page around the services customers recognize: website, API, checkout, dashboard, or client portals. Attach checks that map directly to those names.

• Publish a public status page that shows live monitor state for the services customers recognize.
• Back every public component with a real check so the page reflects measured availability.
• Keep internal-only checks private and route their alerts to email, Slack webhooks, or a generic webhook.

What not to publish

A status page example should not become a catalog of infrastructure. If a user cannot tell whether their workflow is affected, the page has too much internal detail.