The purpose of a postmortem is to make the next incident less likely or less severe. Most postmortems do not achieve that. They produce a document describing what happened, a list of action items, and no change — because the document was written to close the incident rather than to learn from it.
The difference is mostly in how the investigation is framed.
What changed in 2026
- Contributing factors displaced root cause. Recognition that complex failures have many interacting causes, not one root, changed how investigations are framed and written.
- Action item completion got tracked. Measuring whether postmortem actions actually get done exposed how many did not, which changed how many get written.
- Near-miss reviews spread. Reviewing incidents that almost happened, where nothing broke, became a source of learning without the cost of an outage.
- Automated timeline assembly improved. Tooling collecting deploy events, alerts, and chat into a draft timeline removed much of the tedious reconstruction work.
Running the investigation
| Element |
What to capture |
| Timeline |
What happened and when, including what responders knew at each point |
| Detection |
How it was found, and how long that took |
| Impact |
Who was affected and how, in user terms |
| Contributing factors |
Everything that had to be true for this to occur |
| What went well |
Genuinely — this is where you find what to reinforce |
| Action items |
Few, owned, dated |
The timeline should record what people believed at the time, not what was actually true. An incident where responders spent forty minutes investigating the wrong subsystem is telling you something about your observability, and a timeline that only records the eventual correct diagnosis loses that entirely.
Contributing factors, plural, is the right frame. Asking for a root cause pushes toward a single answer, which is usually the last change before things broke — which is rarely the interesting part. A production incident typically required a change, a gap in testing, an alert that did not fire, a runbook that was wrong, and a dependency behaving unexpectedly. Each of those is separately addressable.
Blameless, and why it is practical
Blameless postmortems are frequently justified on cultural grounds. The practical justification is stronger: people who expect consequences do not volunteer the information you need. The engineer who ran the wrong command knows exactly what happened and will describe it accurately only if doing so is safe.
The productive move when human error appears is to keep going. Someone ran a destructive command against production — why was that possible from a normal session, why was there no confirmation, why did the command look safe, why did nothing catch it. Each of those is a system improvement. Stopping at the human is stopping before the useful part.
Actions that get done
Write few. A postmortem generating fifteen recommendations produces a list nobody works through. Three specific actions with named owners and dates have a much better completion rate, and completion is the only thing that matters.
Prioritize by what would have helped most. Faster detection is frequently worth more than preventing the specific cause, because detection improvements apply to the next incident too — which will have a different cause.
Track them. Actions that go into a document and not into the team's actual work queue do not happen. Reviewing open postmortem actions periodically is what closes the loop, and it also reveals when you are generating more actions than you complete.
Feed what you learn back into runbooks immediately, while it is fresh — the maintenance mechanism described in runbook writing guide. And where an incident reveals accumulated debt, that is the strongest argument available for addressing it, per tech debt tracking.
Common mistakes
- Naming a single root cause. Complex failures have several contributing factors.
- Stopping at human error. That is where investigation starts.
- Fifteen action items. Nobody completes them.
- Unowned actions. Never done.
- Timeline of what was true. Should be what responders knew.
- Postmortems on every incident. Reserve the full process for ones with something to learn.
FAQ
Which incidents deserve a postmortem?
Those with meaningful user impact, those that took surprisingly long to resolve, and near-misses that could have been much worse. Not routine handled-by-runbook events.
How soon after the incident?
Within a few days — recent enough that memory is accurate, late enough that people have slept.
Who should attend?
Responders, the service owners, and anyone whose area contributed. Small enough that people talk.
Should postmortems be shared widely?
Within the engineering organization, generally yes. Other teams learn from failures they did not experience.
Where to go next
For the operational procedures, read runbook writing guide. For reliability targets, SLOs and error budgets, and for acting on what you find, tech debt tracking.