Incident Postmortem

Write blameless postmortems documenting what happened, why, and how to prevent recurrence. Focus on systemic improvements, not individual fault.

Workflow

Step 1: Gather Data

Alerts and monitoring data, responder action timeline, communication logs (incident channel, status page), system logs and traces, customer impact data, and prior similar incidents.

Step 2: Reconstruct Timeline

Chronological account: detection (when and how), response (acknowledgment, who responded), diagnosis (hypotheses tested, dead ends), mitigation (impact reduced/eliminated), resolution (root cause fixed), and communication (stakeholder/customer notifications). Record timestamp, action, and actor for each entry.

Step 3: Root Cause Analysis

Apply "Five Whys" or similar. Identify root cause(s), contributing factors (process gaps, technical debt, human factors, organizational issues), detection gaps, and response friction.

Step 4: Assess Impact

Duration, users affected, revenue impact, SLA breach, reputational impact, and data impact (loss, corruption, exposure).

Step 5: Define Action Items

Preventive (address root cause), detective (improve monitoring/alerting), mitigative (reduce future impact), and process (update runbooks/escalation). Each action needs an owner, deadline, and tracking ticket.

Output Format

## Incident Postmortem
**Incident**: [Title] | **Severity**: [SEV1-4]
**Date**: [YYYY-MM-DD] | **Duration**: [X hrs Y min]
**Status**: [Draft / Final]

### Summary
[3-4 sentence blameless summary]

### Impact
| Dimension | Measurement |
|-----------|-------------|
| Duration | [X hrs] |
| Users affected | [N] ([X]%) |
| SLA breach | [Yes/No] |

### Timeline
| Time (UTC) | Event | Actor |
|------------|-------|-------|
| HH:MM | [First sign] | [System] |
| HH:MM | [Alert fires] | [Monitoring] |
| HH:MM | [Mitigation applied] | [Name] |
| HH:MM | [Resolved] | [Name] |

### Root Cause
[Clear explanation]

### Contributing Factors
1. [Factor] -- [Process / Technical / Human / Organizational]

### What Went Well
- [Effective element]

### Action Items
| # | Action | Type | Owner | Due | Tracking |
|---|--------|------|-------|-----|----------|
| 1 | [Action] | Preventive | [Name] | [Date] | [Ticket] |

Examples

User: "Write a postmortem for yesterday's 2-hour API outage" Action: Reconstruct timeline, identify root cause (expired TLS certificate), contributing factors (no expiry monitoring, manual renewal), define actions (automate renewal, add alerting).

User: "Near-miss postmortem -- almost shipped a breaking API change" Action: Document what happened (caught in staging), analyze why not caught earlier (insufficient contract testing), define actions to strengthen the safety net.

Best Practices

• Keep it blameless. "The deploy process allowed an untested change" not "Person X deployed without testing."
• Write within 48 hours while memory is fresh.
• Include "what went well" alongside improvements.
• Every action item needs a single owner and realistic deadline.
• Track action item completion -- postmortems without follow-through are theater.
• Look for patterns across postmortems for systemic fixes.
• Share broadly -- learning extends beyond the affected team.