Incident Communication: [incident]
Incident comms – audiences, message templates
Cómo usar: During incidents, not after. Commit to next-update times and keep them; users forgive outages, not silence.
Vista previa
Incident Communication: [incident]
What to tell users while the system is on fire. Accuracy over speed – a wrong update burns more trust than a slow one.
| Field | Value |
|---|---|
| Incident | INC-NNN |
| Severity | S1 / S2 / S3 |
| Comms lead | @name |
| Started | YYYY-MM-DD HH:MM UTC |
| Status | Investigating / Identified / Monitoring / Resolved |
Audience map
| Audience | Channel | Cadence | Owner |
|---|---|---|---|
| Customers | Status page | Every 30-60 min during S1/S2 | @name |
| Internal | [channel] | Every 15-30 min | @name |
| Key accounts | Direct | As needed | @name |
Message templates
Investigating
We are investigating reports of [symptom] affecting [scope]. Engineers are engaged. Next update by HH:MM UTC.
Identified
We have identified the cause of [symptom] as [short cause]. A fix is being deployed. [Scope] remains affected. Next update by HH:MM UTC.
Monitoring
A fix has been deployed and [metric] is recovering. We are monitoring closely. Next update by HH:MM UTC.
Resolved
[Symptom] was resolved at HH:MM UTC. Total duration: N hours N minutes. A postmortem will be published by YYYY-MM-DD.
Rules
- State what users observe, not internal speculation
- Commit to a next-update time and keep it
- Never promise a fix ETA you cannot defend
- One voice: only the comms lead posts externally
- Postmortem link goes out when published – close the loop