Status Page Templates

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.

A template for each incident state

Most incidents move through four states, and preparing wording for each removes the hardest part of communicating under pressure: figuring out what to say. Keep every template short, and always overwrite the placeholders with the real, current facts.

• Investigating — "We are investigating reports of [impact] affecting [component]. Next update by [time]."
• Identified — "We have identified the cause of [impact] and a fix is in progress. Next update by [time]."
• Monitoring — "A fix has been deployed. We are monitoring recovery and will confirm shortly."
• Resolved — "This incident is resolved and [component] is operating normally. A summary will follow."

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.