When something breaks, tell customers three things: what's affected, that you're on it, and when you'll update them again. Don't wait until you understand the problem — the first update buys you the time to find out.
Copy these, replace the brackets, publish. One update per stage is usually enough.
Investigating — post within 15 minutes
Investigating: [what customers see, e.g. "Slow dashboard loading"]
We're seeing [symptom] affecting [who/what, e.g. "some dashboard users"]. We're investigating and will update this page by [time, max 60 min away].
Say what customers experience, not what you suspect internally. "Dashboard is slow" beats "elevated database latency".
Identified — when you know the cause
Identified
We've found the cause: [one plain-English sentence]. A fix is [in progress / being deployed]. Next update by [time].
You don't need to explain the root cause yet. Name it at whatever level you're confident about.
Monitoring — when the fix is in
Monitoring
A fix is live and [the symptom] should be resolved. We're monitoring to confirm. If you're still seeing problems, [contact route].
Resolved — close it out
Resolved
This incident is resolved. [Symptom] affected [who] between [start] and [end] ([duration]). The cause was [one sentence]. [Optional: one sentence on prevention — only if it's true.]
Rules that keep updates trustworthy
- Commit to a next-update time in every update except Resolved — and hit it, even if the update is "still investigating".
- Never say "we take this seriously" or apologise more than once. State facts; the diligence shows.
- Don't blame a vendor by name while the incident is open. "An upstream provider" is enough.
- Write the Resolved update for someone who saw none of the others — it's the one people find later.