SRE Incident Communication
Fixing the system solves half of an incident. Keeping people informed solves the other half. Calm, honest, regular updates protect trust even when the service stays down.
Who Needs to Hear What
Every audience asks a different question.
| Audience | Main Question | Best Channel |
|---|---|---|
| Responding engineers | What do I do now? | Incident chat room |
| Support team | What do I tell customers? | Support update thread |
| Leadership | How big is the impact and when will it end? | Short summary message |
| Customers | Is the service working and what should I do? | Status page and email |
The Airline Announcement Model
Picture a delayed flight. Passengers stay calm when the pilot announces the reason, the new departure estimate, and the time of the next update. Silence creates anxiety, and false promises create anger. Incident messages follow the same pattern: say what happened, say what you are doing, and say when you will speak again.
A Simple Update Template
- Status: investigating, identified, fixing, monitoring, or resolved.
- Impact: who is affected and what they cannot do.
- Action: what the team does right now.
- Next update: a clear time, such as 3:45 PM.
Message Flow Diagram
[Incident Team] → [Communications Lead]
│
┌───────────────┼────────────────┐
↓ ↓ ↓
[Leadership] [Support Team] [Status Page]
↓ ↓
[Customer Chats] [Customer Email]
A single communications lead keeps the message consistent. Engineers share facts with this person, and the lead shapes the facts for each audience.
Status Page Stages
| Stage | Sample Message |
|---|---|
| Investigating | Some users see errors during checkout. Our team is investigating. Next update at 2:30 PM. |
| Identified | We found the cause in a recent update and prepare a fix. Next update at 3:00 PM. |
| Monitoring | We applied a fix. Checkout works again. We watch results closely. |
| Resolved | Checkout is stable. We will publish a summary within three business days. |
Example Timeline
14:05 Alert fires, engineer declares SEV2 14:10 Incident chat opens, communications lead joins 14:15 First status page post: Investigating 14:45 Cause found, rollback starts, second post: Identified 15:05 Rollback completes, third post: Monitoring 15:35 Metrics stable, final post: Resolved
Writing Rules
Be Plain
Avoid internal code names and technical jargon in customer messages. Write "some payments fail" instead of "the ledger shard returns timeouts."
Be Honest
State only what you know. A message such as "We do not know the cause yet" earns more trust than a wrong guess.
Be Timely
Post the first update within minutes of confirming customer impact. Keep to the promised update schedule, even when the news is "no change."
Be Respectful
Acknowledge the inconvenience in one short sentence. Skip dramatic language, and never blame a person or a vendor in public.
Internal Messages
Leadership wants numbers and decisions. A good internal note lists the affected share of users, the estimated money or time at risk, the current plan, and any decision that needs approval. Keep the note under ten lines.
Common Mistakes
- Waiting for a full diagnosis before telling anyone.
- Promising a fix time with no basis.
- Sending different facts to different groups.
- Forgetting the final all-clear message.
Key Takeaways
Assign one communicator, write short and honest updates, and keep a steady rhythm. Customers forgive outages more easily than they forgive silence.