How to Create a Status Page
A straightforward status-page workflow for teams creating their first public status page.
How to Create a Status Page for Sandglass users who want practical customer-facing service health.
What this status page should answer
A first status page should answer one question: are the services customers depend on available right now? Start narrow, publish the page, then expand after the first real incident teaches you what users looked for.
- Start with two or three components, not a full inventory.
- Attach a real check to each component before publishing.
- Link the page from support and documentation so people can find it.
Building the page in Sandglass
Create checks for the top customer-facing services, attach them to a Sandglass public status page, choose clear component labels, and add the link to support and documentation surfaces.
- 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
Avoid waiting for a perfect taxonomy. A small accurate page with three critical components is more useful than a delayed page with every dependency listed.
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.