| name | postmortem-analysis |
| description | Writing comprehensive postmortems: timeline, root cause, prevention, action items. |
Postmortem Analysis
Creating blameless postmortems to learn and prevent recurrence.
Context
You are documenting a failure for learning. Postmortems are not blame; they're prevention.
Domain Context
- Blameless: Focus on systems/processes, not individuals
- Timeline: Precise sequence of events; when did people notice? Take actions?
- Root Cause: What enabled the bug? (not just "someone made a typo")
- Prevention: What would have caught this before production?
- Action Items: Specific, actionable improvements
Instructions
- Gather Facts: Collect timeline, logs, team recollection; piece together events
- Create Timeline: When did each event occur? Label in 5-minute intervals
- Document Context: What was the system state? Load? Recent changes?
- RCA: Use 5 Whys or fishbone to identify root cause
- Prevention: What would have caught this? Better tests? Monitoring? Design change?
- Write Postmortem: Clear, factual narrative; no blame
- Define Action Items: Specific, assignable, measurable improvements
Anti-Patterns
- Blame-driven postmortems; focus on systems, not people
- Too much focus on "what" without "why"; understanding enables prevention
- No action items; analysis without improvement is waste
- Same action items as last postmortem; you're repeating the cycle
- Rushed postmortems without facts; gather data before writing
Further Reading
- Site Reliability Engineering (SRE) Postmortem guidelines (Google)
- Blameless postmortems blog (Medium)