Incident Communication

Aug 15, 2026 | by openstatus | [education]

Most teams treat incident communication as something that happens to them. The outage starts, someone asks "should we post something?", and a paragraph gets written by whoever is least busy — usually the person who should be fixing it.

It is worth doing better, because the communication is what customers actually experience. They do not see your remediation. They see whether you told them, how fast, and whether the update was honest. A well-run incident with silent comms reads as incompetence; a bad incident with clear comms often ends with customers thanking you.

This is the hub for how to do it: the update stages, cadence by severity, templates per scenario, and the phrases to avoid.

The Four Stages of an Incident Update

Nearly every status page convention — and every template on this site — uses the same four stages. They exist because they answer different questions.

The stage most teams get wrong is Investigating. It feels empty to post "we are looking into it" — so they wait until they have something substantial, and by then customers have been guessing for forty minutes. The first update is not there to inform. It is there to tell people they do not need to open a support ticket.

The other common error is skipping Monitoring and jumping to Resolved. If the fix regresses, you now have to reopen an incident you declared over, which costs disproportionate credibility.

Cadence by Severity

Cadence is the promise you are actually making. The content of an update matters less than posting when you said you would.

Two rules make this work.

Post on schedule even with nothing new. "Still investigating, no change, next update in 30 minutes" is a complete update. Silence is read as abandonment, and the gap between your last update and now is the number customers remember.

Never promise an ETA you are not certain of. A missed ETA converts a technical problem into a trust problem. Promise the next update time instead — that is entirely within your control.

If you have not agreed on what SEV1 means with your team, do that before the next incident: the incident severity matrix explains the tiers, and the severity matrix builder generates one you can adapt.

Templates by Scenario

Copy-paste starting points for the incidents that actually recur, each with wording for all four stages:

• API service disruption — outages and third-party service failures.
• Database performance degradation — slow queries and connection exhaustion.
• Deployment rollback — a release you had to reverse.
• Feature degradation — one capability broken while the product works.
• Network connectivity issues — regional and routing problems.
• Scheduled maintenance — planned work, announced in advance.
• Security incident response — the one with legal and disclosure constraints attached.

Adapt them rather than pasting verbatim. A template's value is that it stops you composing prose at 3am, not that the exact sentences are optimal for your product.

What Not to Say

"Some users may be experiencing intermittent issues." This is four hedges in one sentence. If logins are failing, say logins are failing.

Cause in the first update. Early theories are usually wrong. Correcting a public diagnosis costs more than the twenty minutes of not naming one.

Blaming a provider as an explanation. Naming a dependency is fine as fact. Presenting it as absolution is not — customers bought availability from you, and your provider's outage is your architecture's problem.

Apologies in place of information. One sentence of apology, then facts. A long apology with no detail reads as a company that would rather manage feelings than tell you what is happening.

Marketing voice. No "we're working hard to deliver the best possible experience". Plain, specific, slightly boring — which is what status pages should be.

After the Incident

Resolved is not finished. For anything at SEV2 or above, publish a postmortem: timeline, what actually broke, and what changes so it does not recur. Customers who lost an hour of work want evidence you understand why. Done well it is also surprisingly good marketing — few companies do it, and it demonstrates engineering maturity better than any landing page.

Track MTTR alongside it, but do not confuse the two: MTTR measures how fast you recovered, not how well you communicated while recovering. A team can halve MTTR and still lose customers by saying nothing for an hour.

If you operate under a compliance regime, incident communication is frequently a control rather than a courtesy — see SOC 2, ISO 27001, DORA, and NIS2 for what each expects, including notification deadlines measured in hours.

Where It Gets Published

All of this needs somewhere to land. A status page is the canonical location — one URL customers can check without asking, hosted away from the infrastructure that is failing. Subscribers get updates pushed by email, and you can deliver them into customer Slack channels for the accounts that ask.

Whether that page is public or private is a real decision with different tradeoffs — public vs private status pages covers it. And the updates only get written if something tells you to write them, which is what uptime monitoring is for: the alternative is finding out from a customer.

Frequently asked questions