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 to 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 to 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 to 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 to 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.