Outage Communication Checklist
An outage communication template as a checklist: who to tell, status page updates, update rhythm, customer emails and the final summary during an incident.
- Typical schedule per incident
- The checklist 4 sections, 18 items
- Variables
{{incident_title}} - Start from CI
Use this checklist when an outage or degradation is visible to customers. It runs alongside the technical incident response and belongs to the person handling communications, not to the engineers fixing the problem. In small teams that is often the incident commander, a support lead or a founder. Good communication does not shorten the outage, but it decides how customers remember it.
Who owns it
The communications owner owns the run. They write and send every external update, keep internal teams informed and make sure the next update goes out on time. They get facts from the incident commander and do not interrupt the engineers directly.
Common pitfalls
- Waiting for certainty. Customers notice the outage before you confirm the cause. A first "we are investigating" message, posted quickly, is better than a perfect one later.
- Technical jargon. Customers want to know what is affected, what they should do and when they will hear more. Leave out internal service names.
- Promising a fix time you do not know. Give the next update time, not a guessed resolution time.
- Status page hosted on the broken infrastructure. If your status page runs on the same servers or provider as your product, it goes down with it. Host it separately.
- Forgetting internal teams. Support and sales hear from customers first. Tell them before or at the same time as the public.
Start the run when the incident is declared, so the first message is never forgotten under pressure.
The checklist: Outage communication: {{incident_title}}
First message
-
Communications owner named and confirmed with the incident commander
-
Affected features, regions and customer groups confirmed with the responders
-
Support and customer-facing staff told what is happening and what to say
-
Status page incident posted: what is affected, that you are investigating, next update time
Plain language, no blame and no guessed cause. Example: "Some customers cannot log in. We are investigating and will update by 14:30."
-
Social media or community channels pointed to the status page optional
During the outage
-
Updates posted at the promised times, even when there is no news
-
Each update states current impact, what is being done and the next update time
-
Workarounds shared with customers as soon as they are confirmed optional
-
Key or contractually covered customers contacted directly by their account owner optional
-
Incoming support tickets tagged to the incident and answered with a template
Resolution
-
Recovery confirmed with the incident commander before announcing it
-
Status page updated to monitoring, then to resolved
-
Resolution message sent: what happened in brief, when it was fixed, any action customers need to take
-
Support and customer-facing staff informed that the incident is resolved
After the outage
-
Customer-facing incident summary published for major outages optional
Keep it factual: impact, timeline, cause in plain terms and what you are changing. Publish only after the facts are confirmed.
-
Service credits or SLA obligations checked with the account owners optional
-
Communication timing and wording reviewed in the postmortem
-
Message templates updated with what worked
Checklist as Markdown
Start this checklist from your pipeline
When an incident is declared, POST /api/v1/runs with template "Outage communication: {{incident_title}}" and the incident title.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Outage communication: {{incident_title}}", "variables": {"incident_title": "…"}}'Frequently asked questions
What should an outage notification say?
Say what is affected, who is affected, what you are doing and when the next update will come. Keep it short and in plain language. Avoid guessing the cause or the fix time; customers prefer honest updates to promises that slip.
How often should status page updates be posted?
Choose a rhythm that matches the impact, for example every 30 to 60 minutes for a major outage, and always state the next update time. Keep that promise even when nothing has changed. A missed update makes customers assume the worst.
Should we write a public incident report after an outage?
For major or long outages, a short public summary builds trust, especially with business customers. It should describe the impact, timeline, cause in plain terms and the changes you are making. Check first whether any contracts require specific notification content or timing.
Updated