Status Page Templates
A straightforward status-page workflow for teams planning incident communication.
Status Page Templates for Sandglass users who want practical customer-facing service health.
What this status page should answer
Templates help teams decide component names, incident language, and update cadence before pressure arrives. The value is consistency: every update should say what is affected, what changed, and when the next update is expected.
- Standard wording for investigating, identified, monitoring, and resolved states.
- A fixed cadence so customers know when the next update is due.
- Component names that match what customers actually use.
Building the page in Sandglass
Use Sandglass to expose the component state, then keep your written updates short and tied to the affected check or service. A template should support the monitor signal, not replace it.
- 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 templates that sound polished but hide uncertainty. During an outage, customers prefer a short accurate update over a long generic statement.
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.