Post-Mortem Generator: Blameless Incident Reports
Generate structured, blameless post-mortem documents with timeline, 5-whys root cause analysis, and tracked action items.
# Post-Mortem: [Incident Title] **Date:** 2026-10-21 **Severity:** P2 **Duration:** [X hours Y minutes] **Affected service:** [Service Name] **Author:** [Your Name] **Status:** Draft --- ## Summary [1–2 sentence description of what happened and the customer impact] ## Impact - [Number of affected users/requests] - [Revenue impact if applicable] - [SLA breach: Yes/No] ## Root Cause [Clear, technical description of why the failure occurred. Focus on the system, not individuals.] ## Timeline (all times UTC) | Time | Event | |------|-------| | HH:MM | Monitoring alert fired | | HH:MM | On-call acknowledged | | HH:MM | Root cause identified | | HH:MM | Fix deployed | | HH:MM | Service fully restored | ## 5 Whys 1. **Why did the service fail?** → 2. **Why did that happen?** → 3. **Why did that happen?** → 4. **Why did that happen?** → 5. **Why did that happen?** → ## What went well - [Good things: fast detection, clear runbooks, team collaboration] ## What went poorly - [Bad things: slow alerting, missing runbooks, unclear ownership] ## Action Items 1. [ ] [Action item with owner and due date] 2. [ ] [Action item with owner and due date] 3. [ ] [Action item with owner and due date] --- *This post-mortem follows blameless principles. We seek to understand systems, not blame individuals.*
Frequently Asked Questions
A blameless post-mortem focuses on systemic causes rather than individual fault. The premise: given the information and tools people had at the time, their actions made sense. The goal is to understand how the system allowed the failure, then fix the system — not punish the person.
Write one for any incident that: breached an SLA, required manual intervention by multiple people, lasted longer than expected, could recur, or surprised the team. Many organizations set a threshold like 'any P1/P2 incident or any incident lasting > 30 minutes.'
The 5 Whys is a root-cause analysis technique: you ask 'why?' repeatedly until you reach a systemic cause. Example: Why did the site go down? → DB connection pool exhausted. Why? → A query held connections for 30s. Why? → Missing index on new column. Why? → No migration review process. Why? → Team grew faster than processes.
Aim for 24–72 hours. Soon enough that details are fresh, but not so fast that the team hasn't had time to decompress and think clearly. The review meeting should happen within 5 business days.
Related tools
Need continuous monitoring?
A one-time check is helpful, but 24/7 monitoring catches issues the moment they happen. DevHelm monitors your services every 30 seconds from 4 global regions — free tier includes 50 monitors.
Start Monitoring Free