What is Postmortem?

#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.

#Frequently asked

Which incidents deserve a postmortem?

Any incident with meaningful user impact, plus near misses that could easily have been worse. Near misses are cheap learning.

How soon should it happen?

Within a few days, while memory is fresh and the material is still available. Waiting weeks produces reconstructions rather than recollections.

What makes a postmortem blameless?

Focusing on why the system allowed the failure rather than who performed the action. If a single human error could cause an outage, the system lacked a safeguard.