Incident communication: what to say and when
The words matter less than the timing and the honesty. Post something before customers have to ask, say what you actually know, and update on a schedule you can keep. Here is the timeline and copy-paste templates for each stage.
The four stages, and why they exist
Incident communication tools converge on roughly the same four-stage lifecycle for a reason: it matches how you actually learn about a problem in real time.
- Investigating. You know something is wrong. You do not yet know why.
- Identified. You know the cause. You are working on a fix.
- Monitoring. A fix is deployed. You are watching to confirm it holds before calling it resolved.
- Resolved. Confirmed fixed. No further updates unless it recurs.
Skipping straight from “investigating” to “resolved” is the most common mistake, usually made because the team wants to say something reassuring before they actually have a reassuring thing to say. Post the stage you are actually in, not the stage you wish you were in.
When to post the first update
Before customers have to ask. In practice that means: as soon as your monitoring confirms a real problem, not after a human notices, not after someone in a support queue flags it three times. If your monitoring can auto-draft the first update from a confirmed check transition, let it. The value of the first post isn't its polish, it's that it exists before your support inbox fills up with “is anyone else seeing this?” messages.
A useful discipline: if you would feel embarrassed posting “we are investigating reports of X” because you're not fully sure yet, post it anyway. Uncertainty stated plainly reads as competence. Silence during a visible outage reads as either not noticing or not caring, and customers cannot tell which.
How often to update after that
Pick a cadence you can actually sustain and say what it is. “We will post updates every 30 minutes until resolved” sets an expectation you then have to meet even if the update is “still investigating, no new information.” A stale first post that never gets updated for two hours is worse than three short posts that each say almost nothing new, because a silent gap reads as abandonment, not calm confidence.
For a short, clearly-scoped incident, updating at each real stage change (identified, monitoring, resolved) is usually enough. For anything running past 30-45 minutes with no stage change, post an interim update anyway, even if it just confirms you are still on it.
What to say, and what to leave out
Each update should answer as many of these as you actually know, and no more:
- What is affected (a specific region, a specific feature, everyone).
- What is not affected, if you know that, since it narrows what customers need to worry about.
- What you are doing about it right now.
- When to expect the next update.
Leave out internal blame, speculation you haven't confirmed, and engineering detail that doesn't change what the reader should do. “A database connection pool exhausted” means something to your team and nothing actionable to a customer deciding whether to keep waiting on your product or switch to a competitor for the next hour. Save the technical root cause for the postmortem, where the detail actually has an audience.
Templates
Copy these directly
Fill in the brackets. Keep the structure, since the structure is what makes these fast to write under pressure and fast to read while worried.
Investigating
First post. Post as soon as a real problem is confirmed, even with incomplete information.
We are investigating reports of [symptom, e.g. "elevated error rates on checkout"] affecting [scope, e.g. "customers in our EU region" or "all customers"]. We will post an update within [time, e.g. "30 minutes"] or as soon as we know more.
Identified
As soon as you know the cause, even if the fix isn't deployed yet.
We have identified the cause as [cause, in plain terms, e.g. "a failed deployment to our EU-region servers"]. We are rolling out a fix now. Next update within [time].
Monitoring
A fix is deployed. You're watching metrics recover before calling it resolved.
A fix has been deployed and we are monitoring the results. Early signs are positive: [what you're seeing, e.g. "error rates have returned to normal levels"]. We will confirm full resolution within [time].
Resolved
Confirmed fixed and holding, not just deployed.
This incident is resolved. [Symptom] was caused by [brief cause] and has been fixed as of [time]. [Optional: what changed to reduce recurrence, if you know it already.] We're sorry for the disruption.
Postmortem (published separately, after the incident closes)
Within a few days, for anything that affected customers for a meaningful stretch of time. Not required for every minor blip.
Summary: [one or two sentences, what happened and for how long] Impact: [who was affected, what they experienced] Timeline: [investigating at HH:MM, identified at HH:MM, fix deployed at HH:MM, resolved at HH:MM] Root cause: [the real technical cause, in as much detail as is useful] What we're changing: [concrete follow-up, not "we'll be more careful"]
Maintenance windows are not incidents, and shouldn't read like one
Planned work deserves its own, calmer template: announce it in advance with a start and end time, and don't reuse incident-style urgency language for something you scheduled yourself. A monitor that understands maintenance windows should suppress alerts for the duration automatically so your team isn't paged for downtime you already announced, while the public record of the window still stays visible and honest.
How realuptime status handles this
realuptime status models incidents through the same four stages (investigating, identified, monitoring, resolved), auto-drafts the first update the moment a monitor confirms a real transition, and sends every posted update to subscribers by email automatically. Scheduled maintenance windows suppress alerts for the duration without hiding the window from the public timeline.
Next