Postmortem

A postmortem is a written, blameless analysis conducted after an incident is resolved: what happened, why it happened, and what changes prevent it from happening again. It's triggered by a specific incident, not scheduled on a recurring cadence, and its value depends heavily on people describing what actually happened — including their own mistakes — honestly.

Key components

• Factual timeline — a minute-by-minute (or as precise as possible) reconstruction of what happened, built from logs, alerts, chat messages, and deploy history rather than memory alone.
• Root cause(s) — the underlying reason the incident occurred, found through structured analysis (see Root Cause Analysis) rather than stopping at the first proximate cause that presents itself.
• Contributing factors — conditions that made the incident more likely or worse than it needed to be, even if they weren't the root cause themselves — a missing alert, a stale runbook, an unreviewed change.
• Impact — concretely what and who was affected: duration, customers affected, data involved, revenue or SLA impact.
• Follow-up actions — concrete, specific changes to make, each with a named owner and a target date; "improve monitoring" is not a follow-up action, "add a p99 latency alert on the checkout service by [date], owned by [name]" is.

The blameless principle

A postmortem is blameless: it treats the incident as a result of systems and conditions, not individual failure, and deliberately avoids naming who's "at fault." This matters for a concrete reason — people only describe what actually happened, including the mistake they personally made, when they trust it won't be used against them. A postmortem process that punishes honesty (even subtly, through tone or follow-up) trains people to omit or soften what really happened next time, which quietly destroys the accuracy of every future postmortem.

How it differs from a response plan and a routine reflection

• Postmortem vs. Incident Response Plan — the response plan governs what happens during the incident: roles, escalation, communication. The postmortem happens after the incident is resolved, analyzing what happened and why.
• Postmortem vs. Agile Reflection — a routine reflection (like a sprint retrospective) runs on a fixed schedule regardless of whether anything went wrong. A postmortem is triggered specifically by an incident and scoped to that incident's timeline and causes, not to a general review of the last sprint or period.

Common pitfalls

• Follow-up actions never tracked to completion — a postmortem full of good intentions that are never revisited becomes a document nobody trusts, and the same failure mode recurs because the fix was never actually made.
• Blame creeping in despite the label — phrasing like "X forgot to check Y" or singling out one person's actions, even without saying the word "fault," undermines the blameless principle and chills honesty in the next incident.
• Timeline reconstructed from memory days later — without pulling from actual logs, alerts, and messages, a timeline written from memory drifts from what really happened and can miss the actual sequence that caused the impact.
• Stopping at the first proximate cause — "the deploy caused it" is usually true but incomplete; see Root Cause Analysis for pushing past the first answer to the actual underlying cause.
• No postmortem for near-misses — waiting only for incidents that caused real damage skips the cheaper opportunity to learn from something that almost went wrong.
• Written and filed away, never shared — a postmortem that isn't circulated to the people who could hit the same issue elsewhere loses most of its value.

Learn more

• Incident Response Plan for the tactical process that happens during the incident this postmortem analyzes afterward.
• Root Cause Analysis for the structured technique behind finding genuine root cause rather than the first proximate explanation.
• Agile Reflection for the scheduled, cadence-based counterpart to this incident-triggered analysis.
• Runbook for the step-by-step procedure a postmortem's follow-up actions often end up creating or correcting.