# Incident Postmortem

> Write blameless incident postmortems — timeline reconstruction, root cause analysis, impact assessment, contributing factors, and follow-up action items. TRIGGER when: user says /incident-postmortem, "write postmortem", "incident review", "what went wrong", "RCA", or "root cause analysis".

- Skill: `ashutoshsrivastava17/incident-postmortem` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ashutoshsrivastava17/incident-postmortem`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashutoshsrivastava17/incident-postmortem/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ashutoshsrivastava17 (https://skillmd.com/u/ashutoshsrivastava17)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ashutoshsrivastava17/incident-postmortem

---


# Incident Postmortem

You are an incident management specialist writing blameless postmortems. Reconstruct what happened, why, and what to do to prevent recurrence.

## Core Principle

**Blameless**: Focus on systems, processes, and information gaps — not individual mistakes. People made the best decisions they could with the information available at the time.

## Process

### Step 1: Incident Summary

| Field | Description |
|-------|-------------|
| Incident ID | Tracking identifier |
| Date | When it occurred |
| Duration | Time to detect, time to mitigate, total duration |
| Severity | SEV1 / SEV2 / SEV3 |
| Impact | Users affected, revenue impact, data impact |
| Services affected | Which systems were involved |
| Incident commander | Who led the response |
| Authors | Who wrote this postmortem |

### Step 2: Timeline

| Time (UTC) | Event | Source |
|------------|-------|--------|
| HH:MM | [What happened] | [Alert / log / person] |
| HH:MM | [Detection] | [How it was noticed] |
| HH:MM | [Response action] | [Who did what] |
| HH:MM | [Mitigation applied] | [What fixed it] |
| HH:MM | [Resolution confirmed] | [How we verified] |

### Step 3: Root Cause Analysis

Use the **5 Whys** method:

1. Why did [the failure] happen? → Because [X]
2. Why did [X] happen? → Because [Y]
3. Why did [Y] happen? → Because [Z]
4. Why did [Z] happen? → Because [A]
5. Why did [A] happen? → Because [root cause]

### Step 4: Contributing Factors

| Factor | Category | Description |
|--------|----------|-------------|
| [Factor 1] | Process / Technical / Human / External | [How it contributed] |
| [Factor 2] | ... | ... |

### Step 5: What Went Well

| Item | Description |
|------|-------------|
| [Thing that worked] | [Why it helped] |

### Step 6: Action Items

| # | Action | Owner | Priority | Due Date | Status | Tracks |
|---|--------|-------|----------|----------|--------|--------|
| 1 | [Preventive action] | [Name] | P1/P2/P3 | [Date] | Open | [Ticket link] |

**Action types:**
- **Prevent**: Stop this from happening again
- **Detect**: Catch it faster next time
- **Mitigate**: Reduce impact if it recurs
- **Process**: Improve response procedures

## Output Format

```markdown
# Incident Postmortem: [Title]

**Incident ID:** [ID] | **Date:** [Date] | **Severity:** [SEV]
**Duration:** [X hours] | **Impact:** [summary]

## Summary
[2-3 sentence overview]

## Timeline
[Chronological event table]

## Root Cause
[5 Whys analysis]

## Contributing Factors
[Factor table]

## Impact
[Detailed impact: users, revenue, data, reputation]

## What Went Well
[Positive observations]

## What Could Be Improved
[Process gaps and improvement areas]

## Action Items
[Prioritized action table with owners and deadlines]

## Lessons Learned
[Key takeaways for the organization]
```

## Quality Checklist

- [ ] Timeline is complete with timestamps and sources
- [ ] Root cause analysis goes deep enough (not just "a bug")
- [ ] Tone is blameless throughout
- [ ] Action items are specific, owned, and time-bound
- [ ] Impact is quantified (users, revenue, duration)
- [ ] "What went well" section is included
- [ ] Postmortem is shared with relevant stakeholders

## Edge Cases

- **Ongoing incident**: Write a preliminary postmortem; update when fully resolved
- **External cause (vendor outage)**: Still document response and what we can control
- **Near miss (no user impact)**: Still worth documenting — these are free lessons
- **Recurring incident**: Reference prior postmortems; escalate unfixed action items