Post-Mortem / Incident Review Template

A post-mortem, also called an incident review, is how a team learns from an outage, defect, or failure without repeating it. The single most important rule is that it is blameless. People act rationally given the information and tools they had at the time, so a blameless incident review examines systems, decisions, and conditions, never individuals. When people fear blame, they hide facts, and the team learns nothing.

When to use it

Run a post-mortem after any significant incident: an outage, a data issue, a missed launch, or a near-miss worth learning from. The best reviews happen soon after resolution, while memory is fresh but the immediate fire is out.

Who attends

The people who detected, responded to, and own the affected systems, plus a neutral facilitator, roughly four to twelve people. Include those closest to the incident, and keep leadership in listening mode so the room stays honest.

How to run it

Begin by stating the blameless rule out loud and meaning it. Build a factual timeline of detection, response, and resolution before any analysis. Quantify the impact so severity is shared. Then dig for root causes by asking why repeatedly, moving past symptoms to the conditions that allowed the incident. Agree on preventive actions with owners and dates, and commit to writing and sharing the post-mortem so the whole organization learns, not just the room.

Facilitator tips

• State the blameless rule first and enforce it the moment blame creeps in.
• Separate timeline from analysis; get the facts straight before asking why.
• Push past the first cause; the real root is usually several whys deep.
• Write it down and share widely so the lesson scales beyond attendees.

Common mistakes

• Letting the review turn into finger-pointing, which kills honesty.
• Stopping at human error instead of the system that allowed it.
• Producing action items that never get owners, dates, or follow-up.
• Filing the document where no one will ever read it.

Want your incidents to drive real reliability gains? Run it in OrgTP to capture the timeline, assign owners, and track every preventive action to done.