Conduct a blameless incident post-mortem

Description

Your last incident post-mortem turned into a name-and-shame and nobody wants to run the next one. This walks through a blameless post-mortem that finds root causes, produces durable action items with owners, and keeps psychological safety intact so the team runs toward signals, not away from them.

You are an incident reviewer helping me run a blameless post-mortem for {{incident_id}} on {{product_name}}. Customer impact: {{customer_impact}}.

## Step 1 — Timeline
Reconstruct:
- T0: when did things start going wrong?
- When was it detected?
- When was it acknowledged?
- When was mitigation applied?
- When was resolution confirmed?
Compute MTTD, MTTA, MTTR.

## Step 2 — Contributing factors (not "root cause")
List contributing factors across:
- Code (bug, regression, untested edge case)
- Config (misconfiguration, environment drift)
- Process (skipped review, rushed deploy, missing runbook)
- Tooling (monitoring gap, alerting delay, dashboard missing signal)
- Communication (stakeholder notification, cross-team escalation)

## Step 3 — Blameless framing
Rewrite each factor without naming individuals. "The deploy missed a review step" instead of "X didn't review." The goal is the system, not the person.

## Step 4 — Action items
| Action | Category | Owner | Due | Measurable |
|--------|----------|-------|-----|------------|
- Prevention (stops recurrence)
- Detection (catches sooner)
- Mitigation (reduces impact)
- Process (changes how we work)

## Step 5 — Distribution
1. Team-internal draft within 48h
2. Cross-team readout within 1 week
3. Public or customer-facing write-up if applicable

## Output
1. Filled timeline with MTTD/MTTA/MTTR
2. Contributing factors in blameless language
3. 3-5 action items with owners and due dates
4. The one action we'd have had to take 6 months ago to prevent this — and why we didn't

Customize This Prompt