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.
template · investigating
Investigating: Since [14:02 UTC] we are seeing [elevated error rates on checkout]. Some customers [may be unable to complete payment]. Browsing and existing orders are not affected. We are investigating and will post an update by [14:30 UTC].
2. Identified
You found the cause. Name it in one plain sentence and scope the impact precisely.
template · identified
Identified: The cause is [a failed database failover in our primary region]. [Card payments] are affected; [browsing and account access] are not. A fix is being applied now. Next update by [15:00 UTC].
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".
template · monitoring
Monitoring: A fix was deployed at [15:12 UTC] and [checkout error rates] have returned to normal. We are monitoring closely for the next [30 minutes] before marking this resolved.
4. Resolved
Close with the total duration and, for anything significant, a postmortem commitment with a date.
template · resolved
Resolved: This incident is resolved as of [15:45 UTC]. [Checkout] was degraded for [1 hour 43 minutes]. We are sorry for the disruption. A full postmortem will be published here within [5 business days].
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. If you do not have a format yet, start from our incident postmortem template and report the recovery time using the definition in what MTTR measures.
Outage communication examples in three scenarios worth rehearsing
Templates cover the shape of an update. What trips teams up is the judgment call about which shape to use. These are the three outage communication examples that come up most often, each written the way we would actually post it.
1. Partial degradation, not a full outage
The hardest one, because the instinct is to say nothing while you work out how bad it is. Say something anyway, and be specific about who is affected. Vague sympathy generates more tickets than a narrow, concrete admission.
Investigating. API requests to /v2/reports are returning 504 errors for roughly 15% of accounts since 14:05 ET. Dashboard login, billing and all other endpoints are unaffected. We are investigating and will update by 14:40 ET.
Note the three things that do the work: the exact surface that is broken, the surfaces that are fine, and a time for the next update. A customer who reads that stops guessing and stops writing to support.
2. A total outage where you do not yet know the cause
Do not wait for the cause. The first post exists to prove a human is on it, nothing more. Teams that hold the first update until they can explain the failure routinely take 40 minutes to say anything, which is where the trust damage happens.
Investigating. The application is unavailable for all users from 09:12 ET. We have confirmed the outage from multiple regions and the engineering team is engaged. We do not yet know the cause. Next update at 09:35 ET, whether or not we have one.
"Whether or not we have one" is the most valuable clause in incident communication. It commits you to a rhythm rather than to an answer, so you can keep the promise even when the investigation stalls.
3. The false alarm you already announced
Sooner or later a single-location check fires, you post an incident, and the site was fine the whole time. Retract it plainly and quickly. Quietly deleting the incident is worse, because the people who saw it will assume you hid a real one.
Resolved. The incident posted at 03:14 ET was a monitoring false positive from a single network path, not a service outage. No customer requests failed. We have changed our checks to require confirmation from multiple regions before an incident is opened.
That last sentence is why confirmation matters before an alert ever reaches a human. A check that pages on one failed request from one location will make you publish incidents that did not happen, and each retraction spends a little of the credibility you need for the real one. Requiring several regions to agree is the cheapest fix, and it is the reason our own checks re-run a failure from a second region before anything is sent.
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. If you are still choosing a platform, our roundup of status page software compares what each one automates.
alertping
Your status page, updated before customers finish typing the ticket
AlertPing confirms outages from a second region in seconds, flips your hosted status page automatically, and emails your subscribers. Templates in, trust kept.