Incident communication best practices

The core rules of incident communication: acknowledge within 10 minutes, even with nothing to report yet. Post updates on a stated cadence and keep every promise about timing. Use the four standard states. Write plainly. Publish a postmortem for anything customers noticed.

Customers forgive downtime; they do not forgive silence. During an outage your status page is being refreshed by your angriest users, your biggest accounts and, if it goes on long enough, journalists. Every one of them is deciding whether you are in control. Here is what to post, when, word for word.

The timing rules

• Acknowledge within 10 minutes of a customer-visible incident. "We know and we are on it" posted at minute 8 buys more goodwill than a perfect explanation at minute 45. You do not need a cause to acknowledge impact.
• Name the time of your next update, then hit it. "Next update by 14:30 UTC" turns anxious refreshing into waiting. Missing your own stated time is a second incident.
• Update at least every 30 minutes while unresolved, even when the update is "still investigating, no change". No news reads as abandonment.
• Timestamp everything in one timezone, UTC by convention, and keep the full history visible. Deleting updates later destroys the trust the updates bought.

None of this works if you learn about the outage after your customers do. The 10-minute acknowledgement clock starts at impact, not at discovery, which is why detection in seconds via downtime alerts is the prerequisite for every rule above.

The four status page states, with templates

Status pages converged on four states for a reason: they tell customers exactly where you are in the fight. Copy these, replace the bracketed parts, and you will never stare at an empty compose box mid-incident.

1. Investigating

You know something is wrong. You may not know why. Say what customers see, not what you suspect.

2. Identified

You found the cause. Name it in one plain sentence and scope the impact precisely.

3. Monitoring

The fix is in and metrics look healthy. Do not skip this state: it is what separates "we think it is fixed" from "it is fixed".

4. Resolved

Close with the total duration and, for anything significant, a postmortem commitment with a date.

What not to say

• Do not minimize. "A small subset of users may experience intermittent issues" while checkout is down reads as spin. Customers already know how bad it is; match their reality.
• Do not blame publicly. "Our cloud provider broke" is still your outage in your customers' eyes. Take ownership on the page; sort out vendors privately.
• Do not promise fix times you cannot keep. Promise your next update instead. You control the cadence; you do not control the fix.
• Do not use jargon. "Pod eviction storm in us-east" means nothing to the customer whose invoice run failed. Translate to impact: what stopped working, for whom, since when.
• Do not go quiet after the first post. An "investigating" entry that sits untouched for two hours is worse than nothing; it proves you post and forget.

Postmortem basics

For any incident customers noticed, publish a short postmortem within 5 business days: a plain-language timeline, impact stated in customer terms (who, what, how long), the root cause, and the specific changes that make a repeat less likely. No employee names, no blame. Detection time deserves a line of its own; if it took 11 minutes to notice, say so and say what changes. Honest postmortems are how B2B buyers judge vendors, and they are the paper trail behind every SLA conversation covered in what 99.99 uptime means in an SLA.

The infrastructure that makes this easy

Everything above gets dramatically easier when the mechanics are automated. A hosted status page that flips to "investigating" the moment a confirmed check fails starts your 10-minute clock at zero, emails subscribed customers each update so support stops answering "is it down?", and keeps the incident history that your postmortems and SLA reports are built on. You write the words; the plumbing should already be running.