Post-Incident Review (Blameless Postmortem)

Definition

A post-incident review — historically called a postmortem, and always run blamelessly if it is to be worth anything — is a structured examination of a production incident after it is resolved. It reconstructs the timeline, identifies the contributing factors and produces a small number of concrete actions to reduce the chance or impact of a recurrence. It focuses on systems, not people. Its output is public within the organisation and usually within the affected engineering community.

Why It Matters

Every incident already has a cost — pager wake-ups, customer impact, revenue loss, engineering distraction. The only way to earn something back is to learn from it. Organisations that skip reviews, or run blame-driven ones, keep paying the same tax repeatedly. Organisations that learn make each incident smaller than the last. Over three years, the difference is a system that improves under stress versus one that erodes under it.

What a Review Covers

• Summary — what happened, when, and the customer impact in plain English.
• Timeline — minute-by-minute reconstruction, from first signal to resolution.
• Contributing factors — technical, process and human, without singling out individuals.
• What went well — genuinely, not sycophantically. Detection speed, escalation, communication.
• What went badly — the things that made the incident longer or worse.
• Root cause framing — usually "system of contributing factors," not a single cause.
• Action items — small in number, owned, dated, measurable.
• Follow-up mechanism — who tracks the actions to closure.

Real-World Example

A European grocery retailer had a two-hour checkout outage on a Saturday morning — the worst possible time. The initial hot-take blamed a junior engineer who had merged a database migration late on Friday. The post-incident review, run by a facilitator from a different team, mapped the timeline and found seven contributing factors: the migration script had a subtle interaction with an existing long-running query, the CI environment did not exercise that query, the on-call playbook did not include the specific error signature, the pager alert had a 90-second delay, the escalation path had one person on holiday with no cover, the status page updates were slow, and the rollback script assumed a smaller table. None of those was the "cause." All seven contributed. The action list had five items and shipped within a month. Six months later, a similar migration went in without incident because five of the seven factors were addressed. The junior engineer, incidentally, was never mentioned by name in the final report — and led the fix for two of the action items.

How to Run It Properly

1. Schedule the review within 5 working days of resolution. Memory decays fast and lessons cool with it.
2. Nominate a facilitator who was not on the incident. Neutrality creates safety.
3. Ban "who did it" framing. Replace with "what did the system make easy to do wrong?"
4. Reconstruct the timeline first using logs, chat transcripts and pager data. Only then discuss what to do about it.
5. Cap action items at five. A postmortem with 27 actions produces zero completed actions.
6. Every action has an owner and a due date, tracked in the normal work-tracking system, not a separate document.
7. Publish the report internally. Shared learning is the whole point.
8. Review action item closure quarterly. Repeat incidents are almost always traceable to unclosed actions from a prior review.

Practical Lessons Learned

• Blameless does not mean accountability-free. Individuals still own their actions; the system owns the environment in which they act.
• The most valuable single artefact is the timeline. Everything else follows from it.
• Executive attendance changes the meeting. Invite them to observe, not to interject.
• "Just add more testing" is not an action item. Specific, targeted improvements are.
• Repeat incidents are review failures, not incident failures. If the same class hits twice, the first review was inadequate.

Expert Tips

• Use a template — same headings, every time. Consistency lets patterns emerge across incidents.
• Include customer-visible impact in the summary — not just internal metrics.
• Highlight near misses as well as full incidents. A caught-in-canary bug carries the same lessons at a fraction of the cost.
• Rotate facilitators so the skill spreads across the organisation.
• Read old reports before writing a new one. Half the time the current incident is a variant of a past one, and the past report has the fix.

Common Mistakes

• Naming and shaming — instantly destroys the future signal quality of every review.
• 27-item action lists that no one owns.
• Review scheduled two weeks after the incident, with half the responders unavailable.
• No follow-up on action items — same class of incident recurs six months later.
• Facilitator was on the incident — bias contaminates the analysis.
• Report kept private — organisational learning stalls.

Key Takeaways

• The review is where an incident's cost is converted into organisational learning.
• Blameless means system-focused, not accountability-free.
• Five action items with owners and dates beat 25 without.
• Repeat incidents point to unclosed actions from prior reviews.
• Publish, track and refer back — a review filed away is a review wasted.

Related Concepts

Interlocks with On-Call Rotation, Rollback Plan, Production Readiness Review and Bug Triage. Templates at PMMilestone.org.