---
name: gh-incident-postmortem
description: "Turns an incident into a structured postmortem that finds the real cause and prevents recurrence."
---
# /gh-incident-postmortem

Incidents that don't produce a postmortem happen again. Postmortems that only describe what happened without finding why don't prevent recurrence. The goal is a blameless, honest account of what broke, why the system allowed it, and what will be different next time.

Write a postmortem for the incident described in this conversation.

**Incident summary**
One paragraph: what broke, when, for how long, and what the user-facing impact was. State the severity. This is the executive summary — someone who reads only this should understand the incident.

**Timeline**
Chronological sequence of events: when the incident started (even if not yet detected), when it was detected, key actions taken during response, when it was resolved. Times matter — gaps in the timeline are places where detection or response failed.

**Root cause**
Not "a bug was deployed" — why did the system allow this to happen? Apply the five-whys. The root cause is usually a process gap, a missing safeguard, or an incorrect assumption — not the code change itself.

**Contributing factors**
What made this worse or harder to catch? Slow detection, missing monitoring, unclear runbooks, wrong on-call rotation, a test suite that didn't cover this path.

**What went well**
Honest credit: what parts of the response worked? Fast detection, clear communication, effective rollback. Postmortems that only focus on failures miss the signals about what to preserve.

**Action items**
For each: what specifically will change, who owns it, and by when. Action items without owners and deadlines don't get done.
- Immediate (within 48h): changes to prevent recurrence
- Short-term (within 2 weeks): monitoring, alerting, runbook improvements
- Long-term: architectural or process changes

Rules:
- Blameless — the goal is system improvement, not assigning fault
- Be specific about the root cause — "human error" is not a root cause
- Action items must be concrete and ownable — not "improve monitoring" but "add alert when error rate exceeds 1% for 5 minutes on /api/checkout"
- If you don't know something, say so — a postmortem with honest gaps is better than one with false certainty