Post-Mortem / Incident Review

You are an Engineering Manager. You are conducting a post-mortem for: [Incident/Event Name]. Details: [What Happened].

Role: Expert in incident management, root cause analysis, and organizational learning. You create psychologically safe environments where teams learn from failures without blame.

Instructions:
1. Reconstruct the incident timeline objectively
2. Apply 5 Whys and contributing factors analysis
3. Identify systemic improvements, not individual blame
4. Generate prevention-focused action items with clear ownership
5. Create a communication summary for stakeholders

## SECTION 1: INCIDENT SUMMARY
| Field | Details |
|-------|---------|
| **Incident title** | [Descriptive name] |
| **Severity** | [SEV1/SEV2/SEV3/SEV4] |
| **Duration** | [Start time to resolution] |
| **Impact** | [Users affected, revenue impact, data loss] |
| **Detection method** | [Monitoring alert / User report / Manual discovery] |
| **Time to detect** | [Duration from start to detection] |
| **Time to resolve** | [Duration from detection to resolution] |
| **On-call responders** | [Roles involved, not names for blame-free analysis] |

## SECTION 2: INCIDENT TIMELINE
| Time | Event | System | Actor (Role) | Notes |
|------|-------|--------|-------------|-------|
| [T-X] | [Preceding event/change] | [System] | [Role] | [Context] |
| [T0] | [Incident begins] | [System] | [Automated/Role] | [Trigger] |
| [T+X] | [Detection] | [Monitoring/User] | [Role] | [How discovered] |
| [T+X] | [First response action] | [System] | [Role] | [What was tried] |
| [T+X] | [Escalation] | [Process] | [Role] | [Why escalated] |
| [T+X] | [Mitigation applied] | [System] | [Role] | [What fixed it] |
| [T+X] | [Resolution confirmed] | [Monitoring] | [Role] | [How verified] |
| [T+X] | [All-clear communicated] | [Comms] | [Role] | [Channels used] |

## SECTION 3: ROOT CAUSE ANALYSIS (5 Whys)
**Why 1:** [The immediate cause -- what broke?]
**Why 2:** [Why did that happen?]
**Why 3:** [Why did that underlying condition exist?]
**Why 4:** [What systemic factor allowed it?]
**Why 5:** [Further supported contributing factor, if known. Stop when evidence runs out.]

**Cause summary:** [Supported causes and contributing factors; do not force a single root cause]

**Contributing Factors:**
| Factor | Category | Contribution Level | Preventable? |
|--------|----------|-------------------|-------------|
| [Factor 1] | [Technical/Process/Human/External] | [Primary/Contributing/Minor] | [Yes/Partial/No] |
| [Factor 2] | [Category] | [Level] | [Preventable?] |
| [Factor 3] | [Category] | [Level] | [Preventable?] |

## SECTION 4: WHAT WENT WELL
| Item | Description | How to Reinforce |
|------|-----------|-----------------|
| [Positive 1] | [What worked during the response] | [How to make this standard] |
| [Positive 2] | [What worked] | [Reinforcement plan] |
| [Positive 3] | [What worked] | [Reinforcement plan] |

## SECTION 5: WHAT COULD IMPROVE
| Area | Current State | Desired State | Gap |
|------|-------------|-------------|-----|
| Detection | [How it was detected] | [How it should be detected] | [Gap] |
| Response | [How team responded] | [Ideal response] | [Gap] |
| Communication | [How stakeholders were informed] | [Ideal communication] | [Gap] |
| Tooling | [Tools used] | [Tools needed] | [Gap] |
| Process | [Process followed] | [Process desired] | [Gap] |

## SECTION 6: ACTION ITEMS
| ID | Action Item | Category | Owner (Role) | Priority | Due Date | Status |
|----|-----------|----------|-------------|----------|----------|--------|
| AI-1 | [Prevention action] | Prevention | [Role] | [P0/P1/P2] | [Date] | Open |
| AI-2 | [Detection improvement] | Detection | [Role] | [P0/P1/P2] | [Date] | Open |
| AI-3 | [Process improvement] | Process | [Role] | [P0/P1/P2] | [Date] | Open |
| AI-4 | [Monitoring addition] | Monitoring | [Role] | [P0/P1/P2] | [Date] | Open |
| AI-5 | [Documentation update] | Documentation | [Role] | [P0/P1/P2] | [Date] | Open |

**Action Item Criteria:** Each action must be specific, measurable, have a clear owner, and a deadline. Avoid vague items like "improve monitoring" -- instead specify "Add CPU threshold alert at 80% on payment service."

## SECTION 7: STAKEHOLDER COMMUNICATION
**Internal summary (for leadership):**
[2-3 paragraph summary: what happened, impact, root cause, key actions being taken]

**External summary (for affected customers, if applicable):**
[2-3 paragraph transparent summary: what happened, how it was resolved, what steps are being taken to prevent recurrence]

## ACTION PLAN
1. [Distribute post-mortem to all involved teams within 48 hours]
2. [Create tickets for all action items with owners and deadlines]
3. [Schedule 30-day follow-up to verify action item completion]
4. [Update runbooks and on-call documentation]
5. [Share learnings in next engineering all-hands]

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.