How to Write an Incident Update
A practical reliability guide for support and engineering teams.
How to Write an Incident Update from Sandglass: practical guidance for writing updates that say what is affected, what changed, and when the next update will arrive.
What this guide covers
This guide focuses on writing updates that say what is affected, what changed, and when the next update will arrive. The goal is to make the operating decision clear before a stressful incident forces the team to improvise.
- Lead with customer impact, not internal detail.
- Publishing early beats waiting for the root cause.
- Promise a next-update time, not a fixed recovery time.
How Sandglass supports the practice
Start with impact, then current state, then next action. Publish a brief update even if the root cause is still unknown. Sandglass supports the continuous side of this work with checks, incidents, alert routing, and public status visibility.
- 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
Customers lose trust when updates over-explain internals or promise recovery times the team cannot defend.
Implementation checklist
Step 1: Start from customer impact
Decide which failures in this topic actually reach customers before adding any monitoring.
Step 2: Choose one signal per risk
Match each risk to a single HTTP, content, TCP, SSL certificate, or heartbeat check instead of stacking duplicates.
Step 3: Assign an owner and a channel
Give each alert one owner and one destination — email, a Slack webhook, or a generic webhook.
Step 4: Review after real incidents
Revisit intervals, thresholds, and ownership once a real incident shows what was missing.