Status Page Templates for Incident Communication

What this guide covers

The worst time to figure out how to phrase an incident update is in the middle of the incident. This guide gives you reusable templates for the four states every incident passes through, plus guidance on adapting them with real facts. Prepared templates cut typing when stress is highest — they are a starting point to edit, never a script to hide behind.

• Pre-write the four common incident states.
• Templates cut typing when stress is highest.
• Always edit the template with the real, current facts.

The four incident states

Most incident communication follows the same arc. Prepare one template per state:

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

What each update must contain

Regardless of state, every good update answers three questions: what is affected (in customer terms), what is happening now, and when the next update will arrive. The "next update by" time is the single most important element — it tells anxious customers they can stop refreshing until then, and it holds your team to a communication cadence. Promise a next-update time you can keep, not a recovery time you cannot.

How Sandglass supports the practice

Map each template to the status page components your customers recognize, so publishing an update is a matter of picking the state and filling in specifics. In Sandglass, your components already reflect live check state, so the templates cover the human narrative — impact, cause, and next update — while the indicators track the systems.

• Back the practices here with HTTP, ping, TCP, content, SSL certificate, and heartbeat checks.
• Route incidents to email, Slack webhook channels, and generic webhooks so the right people respond fast.
• Use a public status page to keep customers informed while the team works the incident.

Common mistakes to avoid

Templates should reduce typing, not hide uncertainty. A canned "we are working on it" repeated for two hours with no new facts erodes trust faster than an honest "we still do not have a root cause; next update at 15:00." Keep templates short and always overwrite the placeholders with the current truth.