Status Page Examples
A straightforward status-page workflow for teams comparing status page layouts.
Status Page Examples for Sandglass users who want practical customer-facing service health.
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.
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.
Implementation checklist
Step 1: Name components in customer language
List the services customers recognize — website, API, checkout, dashboard — not internal subsystems.
Step 2: Attach a check to each component
Back every public component with an HTTP, content, TCP, or SSL certificate check so its state is measured, not toggled by hand.
Step 3: Decide what stays private
Keep noisy internal dependencies off the public page and route their alerts to your team channel instead.
Step 4: Publish and link it
Add the public status page link to support replies and documentation so customers can self-serve during incidents.