What is Postmortem?
A postmortem is the structured review conducted after an incident to establish what happened, why the system allowed it, and what should change. Its purpose is to produce durable improvements rather than to assign responsibility.
How a postmortem is conducted
A postmortem documents the timeline first: what happened, when, and what responders observed and did at each point. Facts precede analysis, because analysis built on a fuzzy timeline reaches confident wrong conclusions.
Analysis then examines contributing factors, plural. Real incidents rarely have a single cause, and the useful question is why the system permitted this failure to reach users rather than who made the change. The output is a set of concrete actions with named owners and dates, since a postmortem with vague recommendations produces no change.
Why postmortems matter
Without a review, the same failure recurs and the organization pays for it repeatedly.
- Structural fixes: problems get addressed at their source rather than patched.
- Shared knowledge: what one responder learned becomes available to everyone.
- Pattern detection: repeated contributing factors across incidents reveal systemic weakness.
- Detection improvement: reviewing how the incident was found improves monitoring.
Limits and common failures
The most common failure is that action items are never completed. A postmortem that produces twelve recommendations and no follow through has consumed time and changed nothing, and tracking completion is the difference between a review process and a documentation exercise.
Blame is the other failure. Once a postmortem feels like it is looking for a responsible individual, participants become defensive and the facts get less complete. Blameless practice is not politeness, it is a precondition for getting accurate information.
Postmortem vs root cause analysis
Root cause analysis is a technique for identifying why a failure occurred, and it is one component of a postmortem.
A postmortem is broader. It covers detection, response quality, communication, and the organizational conditions that allowed the failure, in addition to the technical cause. An incident might have a clear technical root cause and still reveal that detection took forty minutes, escalation paths were stale, and stakeholders were never informed. Those are postmortem findings that root cause analysis alone would not surface.
Key takeaways
- A postmortem establishes the factual timeline before analysis, since analysis on a fuzzy timeline misleads.
- Real incidents have multiple contributing factors, and the useful question is why the system permitted the failure.
- Untracked action items are the most common failure mode, turning the review into a documentation exercise.
- Blameless practice is a precondition for accurate information, not a matter of politeness.