A good outage update has four parts: what customers are experiencing, what you know, what you do not know yet, and when the next update will arrive. Post the first one early, keep a steady rhythm, and never state a cause or a time you cannot back up.
Why updates matter
During an outage, silence reads as either incompetence or concealment. Customers can tolerate a failure better than uncertainty. An honest update that says "we are investigating" is better than nothing, and far better than a confident guess that turns out wrong.
Who writes and where
Assign one person to communications, separate from the person fixing the problem. In a small team, this is the incident roles split: lead, scribe and communicator. The communicator writes, the lead approves facts, and nobody else posts.
Use a status page that does not depend on the systems that failed. Mirror the message to support channels so support staff say the same thing.
The four part template
Status line. Investigating, identified, monitoring, or resolved. Keep the vocabulary small and consistent.
Impact. Describe what users see, in their words. "Some customers cannot log in" is better than "elevated authentication errors". Say who is affected and who is not, if you know.
What we know and what we are doing. One or two sentences. Name actions, not blame. If a provider is the source, say so without making it an excuse.
Next update. Promise a time and keep it. If you have nothing new, post that at the time promised.
Examples
First update: "We are aware that some customers cannot sign in. We are investigating and will post another update within 30 minutes."
Mid incident: "We have identified a problem with a cloud region that hosts part of our service. We are moving traffic to a secondary region. Sign in may be slower than usual. Next update by 14:30 UTC."
Resolution: "Service has been restored. Customers who tried to complete a purchase between 13:10 and 13:55 UTC should check their order status. We will publish a full review within five business days."
Adjust times and wording to your case. Do not copy numbers from examples into a real notice.
Mistakes to avoid
- Guessing at cause. Naming a cause too early creates a correction later. Say you are investigating.
- Promising a fix time you cannot control. If you depend on a provider, say you are waiting on them, and when you will next check.
- Technical jargon. Customers need impact, not internals. Put detail in the postmortem.
- Minimizing. "Minor issue" followed by a six hour outage costs trust.
- Going quiet after the fix. Post a resolution message and say when the review will follow.
- Mentioning data exposure without checking. If there is any chance of a security event, involve your security and legal contacts before you post. For separating outage from attack, see outage or attack.
After the incident
Publish a short, blameless review. Google's SRE guidance describes a postmortem as covering impact, the actions taken to mitigate or resolve, root causes and follow up actions, and it states that writing one is a learning opportunity, not punishment. For customers, a shorter version is fine: what happened, how long it lasted, what you changed. See the blameless postmortem template.
If you have contractual or regulatory notification duties, such as for security incidents, check the rules for your sector early. Those timelines can be short and are separate from status page courtesy.
Prepare now
Keep drafts of these templates in your runbook, along with the status page login and a backup way to publish. Rehearse once in a tabletop exercise so the communicator has used the tool before.
Quick check
How often should we post updates?
On the schedule you promised in the last update. If nothing has changed, post that, rather than going quiet.
Should we name the cause in the first update?
Not unless it is confirmed. Say you are investigating, then share facts as they firm up.
Sources
Last reviewed: 19 October 2026.
