The Incident Decision Log
Decisions during incidents are forgotten. The log that captures what was decided and why.
What to log
The decision log captures the major choices made during an incident and the reasoning behind each one. Not every action; just the inflection points where the response changes direction.
- Major decisions only. Rollback-or-not, escalate-or-not, fix-A-or-fix-B. Inflection points where the response changes direction.
- Reasoning included. Per-decision the why. What alternatives were considered, what the gamble looks like.
- Timestamp per entry. Explicit local time. Supports later timeline reconstruction without guessing.
- Named decider per entry. Incident commander or named lead. Future “who decided” questions have a clean answer.
When
The log lives in the incident channel, written in real time. One-line entries by IC or scribe so the discipline does not break investigation flow.
- Real time, in the channel. Live capture. Memory-based reconstruction after the fact loses detail and ordering.
- IC or scribe owns the writing. Named writer. Without ownership, decision capture falls through cracks during high-tempo incidents.
- One-line entries. Short notes that do not interrupt the work. Long-form context belongs in the postmortem.
- Structured prefix.
DECISION:tag in front of every entry. Later grep across incidents becomes trivial.
Use
The log pays back at postmortem time and during future similar incidents. Postmortem timelines write themselves; future incident commanders learn from the past without reading every postmortem.
- Postmortem reconstruction. Log-driven timeline cuts hours off the writeup. The narrative falls out of the entries.
- Future-incident reference. Past decisions in similar contexts inform faster choices the next time around.
- Searchable archive. Org-wide decision-log index supports cross-incident pattern recognition over the year.
- Quarterly decision-quality review. “Did the decision work” retros support incident-commander training without singling anyone out.