A practical structure for incident postmortems: executive summary, impact, timeline, 5-Whys root cause, action items — plus the mistakes that make postmortems useless.
You are not writing literature. A postmortem is a decision document: its job is to make sure the same outage doesn't happen twice, and to give leadership an honest picture without finger-pointing. Here is the structure we use, section by section, with the mistakes that quietly kill usefulness.
1. Metadata. Date, severity, duration, affected services, author. Fifteen seconds of value — put it at the top so skimmers can triage.
2. Executive summary. Three to five sentences anyone can read: what broke, what it cost, how it was fixed, and how confident you are about the cause. Write this last; everyone reads it first.
3. Impact. User-facing first: percentage of requests failed, accounts affected, revenue exposure, whether any data was lost or corrupted. Vague impact statements ("some users saw errors") get stale fast because nobody can tell if things got better.
4. Timeline. A table, reverse-engineered from chat logs, deploy records, and alert history. Each row: time, event, source. Sources matter — when someone challenges a claim two months later, you can prove where it came from.
5. Root cause via 5 Whys. Chain "why did this happen" five times until you hit a systemic answer ("no guardrail existed"), not a person-shaped one ("engineer made a typo"). If your chain ends at a name, you haven't finished. Hedge honestly when unverified: say "working hypothesis" and mark unknowns as TODO instead of inventing causes — a confident wrong root cause is worse than an honest gap.
6. Detection & recovery commentary. How was it detected — automated alert or a human noticing? What's your MTTD and MTTR? What would have halved them?
7. Action items. Every item typed (prevent / detect / mitigate), owned by a named person, prioritized. Untyped, unowned items are wishes, not actions; delete them.
If the timeline lives in Slack and the format above matches what your org expects, tools like postmort.dev generate the structured draft from your raw notes in about ninety seconds — leaving you the review meeting to argue about actual causes rather than formatting tables.
Paste your incident timeline and get this exact structure filled out in ~90 seconds.