🔍 Post-Mortem & Incident Review

Learning from failures and incidents without blame.

Purpose

A post-mortem is a structured review after an incident or project failure. The goal is to learn and prevent recurrence, not to assign blame.

Post-mortem process

1. Timeline — Reconstruct what happened, when, and who was involved
2. Root cause analysis — Use the 5 Whys to dig deeper
3. Impact assessment — What was affected? Users, revenue, reputation?
4. What went well — What worked during the response?
5. What went wrong — Where did things break down?
6. Action items — Specific, assigned, time-bound improvements

5 Whys example

Problem: Deployment caused 2h outage
Why? → Config file was wrong
Why? → It wasn't reviewed before deploy
Why? → No review step in the deploy process
Why? → Deploy process was never formalized
Why? → Team grew fast, process didn't scale
→ Action: Formalize deploy checklist with mandatory review

Post-mortem template

Field	Content
Date	...
Severity	P1 / P2 / P3
Duration	...
Summary	One paragraph
Timeline	Chronological events
Root cause	5 Whys result
Impact	Users, systems, business
Action items	What, who, by when

Best practices

• Hold the post-mortem within 48 hours
• Blameless culture — focus on systems, not individuals
• Share findings broadly to prevent similar issues elsewhere
• Follow up on action items in the next sprint
• Archive post-mortems as organizational knowledge