The blameless post-mortem principle

The most important rule: post-mortems are about systems, not people. When an incident happens, it's almost never because one person made a careless mistake. It's because the system allowed — or even invited — that mistake. A deployment process that doesn't require a second review, a monitoring setup that doesn't alert until 30 minutes after an outage starts, a test suite that doesn't cover that edge case.

If your post-mortem ends with "we told the developer to be more careful," you haven't run a post-mortem. You've had a performance review. The next incident will happen for the same reason.

When to run a post-mortem

For smaller incidents or near-misses, a brief written summary (5 minutes, no meeting) is sufficient. Reserve the full post-mortem process for significant incidents.

The post-mortem template

INCIDENT POST-MORTEM Incident Title: [Brief description, e.g., "Payment processing outage — June 14, 2025"] Date of Incident: [Date] Duration: [How long from detection to resolution] Severity: Critical / High / Medium Author: [Name] Reviewers: [Names] --- TIMELINE [UTC or IST times throughout] 14:23 — Incident began (what triggered it) 14:31 — First alert fired (or how it was detected) 14:35 — On-call engineer paged 14:52 — Root cause identified 15:17 — Mitigation deployed 15:24 — Full service restored --- IMPACT - Users affected: ~1,200 (all users attempting checkout) - Revenue impact: ~₹2.4L in blocked transactions - Duration of customer impact: 61 minutes --- ROOT CAUSE [What actually caused this — one paragraph. Be specific. "A configuration change deployed at 14:15 removed the API timeout setting, causing payment gateway calls to hang indefinitely and exhaust the connection pool within 8 minutes."] --- CONTRIBUTING FACTORS [What conditions allowed this to happen or made it worse] - Config change was not reviewed before deployment - No alert for connection pool utilisation - Runbook for payment failures was out of date --- WHAT WENT WELL - Detection was fast once the alert fired - Team communication on the incident Slack channel was clear - Rollback process worked as expected --- ACTION ITEMS | Action | Owner | Due Date | |--------|-------|----------| | Add peer review requirement for config changes | [Name] | [Date] | | Add connection pool alert at 80% utilisation | [Name] | [Date] | | Update payment failure runbook | [Name] | [Date] |

⚠️ Action items without due dates and owners get done 0% of the time. Every action item must have one named owner and a specific date — not "next sprint" or "soon."

Running the post-mortem meeting

The meeting should happen within 48 hours of the incident being resolved, while details are fresh. Format:

  1. Walk the timeline (10 min) — the author presents what happened, in order, factually
  2. Root cause discussion (15 min) — ask "why" 5 times until you reach a systemic cause, not a personal one
  3. What went well (5 min) — don't skip this; it anchors the blameless culture and identifies things worth preserving
  4. Action items (10 min) — assign owner and date to each item before the meeting ends

Total: 40 minutes. More than this and people lose focus. Less than this and you haven't done the work.

The 5 Whys technique

Use this to find the real root cause instead of stopping at the surface:

Root cause: No peer review process for configuration changes. Action item: Add config change review to deployment checklist.

Track post-mortem action items in Resolvo

Log incidents, assign action items, track completion. Issue tracking built for engineering teams. Free to start.

Try Resolvo Free →