GEO GUIDE
Writing a Postmortem: Blameless and Useful
Updated 2026-10-19 · this page makes no search or citation promises
The direct answer: an effective postmortem answers four questions — what happened, how bad, why, and how to prevent recurrence. Five parts: timeline, impact, root cause, actions, lessons. The core principle: follow the process, not the person — a postmortem that names individuals makes sure nobody reports honestly next time.
The direct answer: an effective postmortem answers four questions — what happened, how bad, why, and how to prevent recurrence. Five parts: timeline, impact, root cause, actions, lessons. The core principle: follow the process, not the person — a postmortem that names individuals makes sure nobody reports honestly next time.
The timeline
- Events in order: detection, response, diagnosis, recovery — each with a UTC timestamp.
- Facts, not judgements: “14:02 monitoring alerted”, not “14:02 the problem was finally noticed”.
Quantified impact
- Users affected, duration, business metrics — data, not adjectives.
- Honest on both sides: inflating impact spends trust; understating it delays improvement.
Root cause
- Ask why five times, stopping at a process that can be improved (not “human error” — the root cause of human error is always a process that allowed it).
- Separate the proximate cause from the systemic one: this time a config error — what made a config error possible?
Actions
- Each action has an owner and a deadline.
- Only actions that prevent this class of incident — not generic “improve monitoring”.
- Five actions maximum — more means the root cause analysis is not focused.
Boundary
Postmortems are readable by everyone by default (transparent postmortem culture is worth more than secrecy); personal details are anonymised. This is a structural method, not a replacement for an incident management process.