A postmortem — a written account of an incident (an outage, a serious bug in production, a significant near-miss), produced after the immediate fire is out — is a specific document with a specific purpose: understanding what happened well enough to reduce the chance of a similar failure in the future. That purpose sounds obvious, but it conflicts directly with a much more common, informal instinct after something breaks: figuring out who made the mistake. The two goals pull in genuinely different directions, and a postmortem process has to choose deliberately between them to be useful. A well-known operational reference is the Google SRE postmortem culture chapter.
Why blame and understanding are in tension
Once a postmortem process is understood, even implicitly, as an exercise in identifying who's at fault, people's incentives during the process change in a way that directly undermines the document's stated purpose: participants become more careful about what they disclose, more likely to frame their own actions favorably, and less likely to volunteer the small, honest details — I wasn't sure what that config flag did, I assumed someone else had checked that — that are often exactly the details that explain why a reasonable, competent person made a decision that, with hindsight, contributed to the failure. A blame-oriented process produces a document that protects individuals; a genuinely useful postmortem needs a process that protects honesty instead. Where staffing availability affects delivery plans, the linked resource provides additional context.
This is the reasoning behind the common practice of an explicitly blameless postmortem: the process is structured, often with an announced norm at the start, around the premise that the people involved made reasonable decisions given what they knew and the pressures they were under at the time, and the goal is understanding the systemic conditions that made a reasonable decision produce a bad outcome — not identifying an individual to hold responsible for it.
What a good postmortem actually documents
Beyond a blameless framing, a useful postmortem tends to include a small set of specific things: a factual, timestamped timeline of what happened and when, separated clearly from any interpretation or judgment about it; the immediate, proximate cause of the failure; the deeper contributing factors that allowed the proximate cause to actually cause an incident (missing monitoring that would have caught it sooner, a process gap that let an untested change reach production, ambiguous ownership that delayed the response); and a specific, prioritized list of concrete follow-up actions, each with an owner, rather than a vague general commitment to “be more careful.”
- Separate the factual timeline from interpretation and judgment — write down what happened and when before analyzing why, to avoid the analysis quietly distorting the record of events.
- Look past the proximate cause to the contributing systemic factors — the specific bug that triggered an incident is usually less useful to fix than the conditions that let it reach production and cause damage undetected.
- “Be more careful” is not an actionable follow-up item — a useful action is specific, has an owner, and is something that would have prevented or caught this specific class of problem.
- A blameless framing has to be genuine and consistently applied, not just stated at the start of a document — a postmortem process that's blameless in name but still results in individual consequences will quickly stop producing honest accounts.
Why the discipline pays off beyond the immediate incident
A well-run postmortem process, sustained over time, tends to surface the same small set of systemic weaknesses repeatedly across seemingly unrelated incidents — inadequate monitoring in a specific area, an unclear on-call handoff process, a class of change that keeps slipping past review — which is genuinely valuable information that a blame-focused process, optimized for closing out any single incident quickly rather than for pattern-finding across many, tends not to surface as reliably.
Connected to the continuous delivery and feature-flags guides discussed elsewhere on this shelf, a mature postmortem practice is one of the clearest signs that a team has shifted from treating individual failures as isolated events to treating them as information about the system — process, tooling, monitoring — that produced them.