During an incident
Roles#
| Role | Does | Does not |
|---|---|---|
| Incident lead | Decides, delegates, keeps the timeline | Debug in depth |
| Responder | Investigates and applies fixes | Answer stakeholders |
| Communicator | Posts updates internally and externally | Change anything |
On a small incident one person holds all three, and that is fine. The moment a second person joins, say out loud who is lead — the most common failure in a staffed incident is that everybody assumes somebody else is leading.
The channel#
One place, for everything. Side conversations in direct messages are invisible to the write-up and cause two people to act on different information — and the channel doubles as the timeline for free.
Updates#
Post an update when something changes, and on a fixed interval even when nothing has. Four lines is enough:
- What is broken, in user terms.
- What we believe is causing it, and how confident we are.
- What we are doing right now.
- When the next update will be.
"No change, still investigating, next update in 30 minutes" is a complete update. Silence is read as either "fixed" or "abandoned", and it is never either.
Keeping the timeline#
The lead notes decisions and actions with times as they happen — not a transcript, just the turning points: when the symptom started, when someone noticed, what was tried, what changed. This is the part nobody can reconstruct later, and it is most of a good postmortem.
Calling it over#
Say explicitly that the incident is closed, state what is still degraded if anything, and name who is writing it up. An incident that fades out instead of ending never gets written up.