# 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