What is a post-mortem — and what makes one actually useful.
Short answer
A post-mortem is a structured review conducted after a significant incident, failure, or project completion. Its goal is to understand what happened, why it happened, and how to prevent it from happening again. A good post-mortem produces a shared timeline, a root cause analysis, and 3–7 specific action items with owners and deadlines. It is distinct from a blame session — the best post-mortems are blameless.
The term "post-mortem" (Latin: "after death") was adopted from medicine into engineering and project management to describe the analysis of a significant failure or completion event.
Two types of post-mortems.
Incident post-mortem (SRE/engineering). Run after a production outage, security incident, or significant service degradation. Typical trigger: any incident that lasted more than 30 minutes, affected more than 1% of users, or required emergency on-call response. Output: a published document with timeline, root cause, impact, and action items. Distributed to the entire engineering organization and kept as a reference.
Project post-mortem. Run at the end of a project, launch, or product phase. Broader scope — not just failure, but anything that went differently than planned (positive or negative). Output: a session debrief document that the team uses to improve the next project. Less formal than an incident post-mortem but same structure.
The post-mortem document. A well-structured post-mortem contains:
- Impact statement — who was affected, for how long, at what severity
- Timeline — what happened, when, in chronological order
- Root cause — the deepest systemic cause found by Five Whys or fishbone analysis
- Contributing factors — environmental or process conditions that made the failure more likely
- What went well — responses or systems that worked correctly during the incident
- Action items — specific, owner-assigned, deadline-bounded preventive measures
Blameless post-mortems. The most effective post-mortems separate people from systems. Rather than naming who made a mistake, they ask what process, tool, or design allowed the mistake to happen. This is not about avoiding accountability — it's about producing better mitigations. Individual accountability is handled separately by management; the post-mortem process is for organizational learning.
Publication. Post-mortems should be published internally within 48–72 hours of the incident being resolved. Publishing them (even for failures) signals a learning culture and prevents the same failure from happening to teams who weren't directly involved.
Teams that conduct post-mortems at a whiteboard — building the timeline, clustering contributing factors, writing action items — get better outputs than those who write the document solo afterward. Snap the whiteboard with BoardSnap and the AI produces the first draft of the post-mortem document, saving 30–60 minutes of write-up time.
Frequently asked
What is the difference between a post-mortem and a retrospective?
A retrospective (or retro) is a scheduled cadence meeting run at the end of every sprint to improve team process. A post-mortem is triggered by a specific incident or failure and focuses on root cause analysis of that specific event. Both produce action items with owners, but retros are broad and cadence-based; post-mortems are event-triggered and incident-specific.
Should post-mortems be published publicly?
Some companies publish post-mortems externally — notably Cloudflare, GitHub, and PagerDuty. Public post-mortems build customer trust and are a mark of engineering maturity. The decision depends on the sensitivity of the incident and the company's communication norms. All post-mortems should at minimum be published internally.
How long should a post-mortem document be?
1–3 pages for most incidents. Longer post-mortems often contain unnecessary detail that obscures the key learnings. The most important sections are the root cause and the action items — these should be readable in under 5 minutes by someone who wasn't involved in the incident.
See it work in ten seconds.
BoardSnap is free on the App Store. Snap a board — get a summary and action plan.