Incident Postmortem

Use this when a production incident has been resolved and the team needs to learn from it -- or when you're facilitating a postmortem for a client team. Also use proactively to establish postmortem culture before the first incident hits. Also works as a project or engagement postmortem -- reflecting on completed work to capture lessons learned without incident-specific framing. Produces a postmortem document with timeline, contributing factors, severity classification (or goal assessment), and tracked action items.

Related skills: Use /delivery-diagnose when the problem is chronic delivery issues rather than a discrete incident. Pair with /instrumentation-plan to improve detection for future incidents. Use /observability-plan if the incident revealed blind spots in product-level monitoring. For significant or recurring problems that need corrective + preventive action with effectiveness verification, feed postmortem findings into /capa-design.

Process

Step 1: Gather inputs

Ask the user to provide: 0. Postmortem type -- incident (default) or project/engagement? Project mode replaces severity classification and incident timeline with outcome reflection and goal achievement assessment.

1. Incident summary -- what happened, in plain language?
2. Severity -- how bad was it? (Use the team's existing severity levels, or classify below.)
3. Timeline data -- alerts, Slack messages, on-call pages, deploy logs, status page updates, customer reports. Raw is fine -- we'll structure it.
4. Resolution -- what fixed it? Who was involved?
5. Impact -- users affected, revenue impact, data loss, SLA breach, reputational cost.
6. Team context -- who was on call? What's the team's postmortem experience level?

If severity levels don't exist yet, use this default scale:

If project/engagement postmortem: Skip the severity table. Instead gather:

• Original goals and success criteria -- what were we trying to achieve?
• What was delivered vs. planned -- scope, timeline, quality
• Stakeholder feedback -- what did clients/sponsors say?
• Team composition and dynamics -- who was involved, how did collaboration work?
• Timeline -- planned vs. actual milestones

Step 2: Reconstruct the timeline

Build a chronological timeline from the raw data. For each entry, capture:

### Timeline

| Time (UTC) | Event | Source | Actor |
|-----------|-------|--------|-------|
| (timestamp) | (what happened) | (alert / Slack / deploy log / customer report) | (person or system) |

**Key timestamps:**
- **Detection:** (when did we first know?) -- (how: alert / customer report / engineer noticed)
- **Escalation:** (when did the right people get involved?)
- **Mitigation:** (when was the bleeding stopped?)
- **Resolution:** (when was the root fix applied?)
- **Communication:** (when were customers/stakeholders informed?)

**Time gaps to investigate:**
- Detection to escalation: (N minutes) -- (acceptable? too slow?)
- Escalation to mitigation: (N minutes) -- (what slowed this down?)

Flag any gaps where "we don't know what happened" -- those are learning opportunities, not failures.

Step 3: Identify contributing factors

Use a contributing factors analysis, not "root cause analysis." Incidents rarely have a single root cause -- they emerge from the interaction of multiple contributing factors.

Categorize contributing factors:

### Contributing factors

**Process factors:**
- (e.g., "Deployment happened on Friday afternoon with no one watching metrics")
- (e.g., "Runbook was outdated -- referenced services that were decommissioned 6 months ago")

**Technical factors:**
- (e.g., "No circuit breaker on the payment service dependency")
- (e.g., "Database connection pool exhaustion under load -- no connection limit alerting")

**Human factors:**
- (e.g., "On-call engineer was unfamiliar with the payment service -- joined the team 2 weeks ago")
- (e.g., "Alert fatigue -- 47 low-priority alerts in the previous 24 hours masked the real signal")

**Organizational factors:**
- (e.g., "No staging environment that mirrors production load patterns")
- (e.g., "Team responsible for the failing service was dissolved last quarter -- no clear owner")

Blameless framing rules:

• Name roles, not people. "The on-call engineer" not "Alex."
• Describe what happened, not what someone should have done. "The alert was not actionable" not "They ignored the alert."
• Ask "what made this outcome likely?" not "who caused this?"
• Treat every human action as reasonable given what they knew at the time.

Step 4: Assess detection and response

Evaluate how well the system and team responded:

### Detection and response assessment

| Phase | What happened | What worked | What didn't |
|-------|-------------|-------------|-------------|
| Detection | (how was it discovered?) | (good: automated alert fired in < 2 min) | (bad: alert was noisy, buried in other alerts) |
| Triage | (how was severity assessed?) | (good: clear severity rubric existed) | (bad: took 20 min to determine customer impact) |
| Communication | (who was notified, when?) | (good: status page updated within 5 min) | (bad: internal Slack channel was wrong, half the team missed it) |
| Mitigation | (how was bleeding stopped?) | (good: feature flag killed the bad code path in 3 min) | (bad: rollback took 45 min because deploy pipeline was queued) |
| Resolution | (how was it fully fixed?) | (good: fix was straightforward once understood) | (bad: no tests existed for this code path) |

Step 5: Generate the postmortem document

## Postmortem: {{incident title}}

**Date of incident:** {{date}}
**Severity:** {{SEV level and label}}
**Duration:** {{detection to resolution}}
**Author:** {{who wrote this}}
**Postmortem date:** {{when this review happened}}

### Summary
(2-3 sentences: what happened, what the impact was, how it was resolved.)

### Impact
- **Users affected:** (number or percentage)
- **Duration of impact:** (time from user-facing impact start to resolution)
- **Revenue impact:** (if measurable)
- **SLA impact:** (any SLA breach?)
- **Data impact:** (any data loss or corruption?)

### Timeline
(From Step 2)

### Contributing factors
(From Step 3)

### Detection and response assessment
(From Step 4)

### What went well
- (Things that worked during the incident -- call them out explicitly)
- (Fast detection, clear communication, effective mitigation, good teamwork)

### Action items

| ID | Action | Type | Owner | Due date | Status |
|----|--------|------|-------|----------|--------|
| 1 | (specific action) | Prevent / Detect / Mitigate / Process | (team or role) | (date) | Open |
| 2 | (specific action) | (type) | (team or role) | (date) | Open |

**Action item types:**
- **Prevent:** Stop this class of incident from happening (e.g., add input validation)
- **Detect:** Catch it faster next time (e.g., add alerting on connection pool usage)
- **Mitigate:** Reduce impact when it does happen (e.g., add circuit breaker)
- **Process:** Improve how we respond (e.g., update runbook, rotate on-call training)

### Follow-up schedule
- **Action item review:** (date -- 2 weeks after postmortem)
- **Retro check-in:** (date -- next retro to confirm actions are progressing)

If project/engagement postmortem, use this template instead:

## Project Postmortem: {{project or engagement name}}

**Engagement period:** {{start date}} -- {{end date}}
**Team:** {{team members and roles}}
**Author:** {{who wrote this}}
**Postmortem date:** {{when this review happened}}

### Summary
(2-3 sentences: what the project was, what was delivered, overall assessment.)

### Goals vs. Outcomes

| Goal | Target | Actual | Assessment |
|------|--------|--------|------------|
| (goal 1) | (success criteria) | (what happened) | Met / Partially met / Not met |

### What went well
- (Practices, decisions, or dynamics that worked)

### What we would do differently
- (Specific changes, not blame -- what would we adjust if starting over?)

### Lessons learned

**Process:** (what we learned about how we work)
**Technical:** (what we learned about the technology or architecture)
**People:** (what we learned about team dynamics, communication, collaboration)
**Client:** (what we learned about stakeholder management, expectations, engagement)

### Recommendations for future engagements
- (Reusable patterns, warnings, or advice for the next team)

### Action items

| ID | Action | Owner | Due date | Status |
|----|--------|-------|----------|--------|
| 1 | (specific action) | (person or team) | (date) | Open |

Step 6: Facilitate the postmortem meeting (optional)

If the user is facilitating a live postmortem, provide this agenda:

1. Set the tone (2 min) -- "This is a blameless postmortem. We're here to learn, not to assign blame. Every action taken during the incident was reasonable given what people knew at the time."
2. Walk through the timeline (10 min) -- present the timeline, ask for corrections and additions.
3. Discuss contributing factors (15 min) -- present the factors, ask "what else made this outcome likely?"
4. Identify action items (10 min) -- for each contributing factor, ask "what would reduce the likelihood or impact of this factor?"
5. Prioritize actions (5 min) -- rank by leverage (prevent > detect > mitigate > process) and effort.
6. Assign owners and dates (5 min) -- every action item gets an owner and a due date. No orphan items.
7. Close (3 min) -- confirm follow-up schedule, thank the team.

Facilitation tips:

• If someone starts blaming, redirect: "Let's focus on what made that outcome likely, not who did what."
• If the group fixates on a single root cause, ask: "What else had to be true for this to happen?"
• If action items are vague, push for specificity: "What does 'improve monitoring' mean concretely? What metric, what threshold, what alert?"

Step 7: Discuss

Ask the user:

• Does this capture the incident accurately?
• Are there contributing factors we missed?
• Are the action items concrete enough to execute?
• Should I draft a customer-facing summary or internal announcement?
• Want me to set up a follow-up action item review prompt?

Output location

Present the postmortem document as formatted text in the conversation or save to a file if requested.