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: start with two or three customer-facing components, back each with a real check, publish, and link it from support — then expand.
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.
Your first status page in four steps
Creating a status page is quick once you resist the urge to be exhaustive. Start small, publish, and let real incidents guide expansion.
- List the two or three services customers depend on most, named in their language.
- Create a check for each — HTTP or content for web surfaces, a heartbeat for a critical job — so the component reflects measured state.
- Attach the checks to a public status page and give each a clear label.
- Publish it and link it from your support replies and documentation so customers can find it during an incident.
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.