postmortem-analysislisted

# Postmortem Analysis Turn an incident into changes that prevent the next one, without turning it into a search for someone to blame. ## Purpose **Use this when:** - An incident is resolved and needs a write-up. - Reviewing someone's postmortem draft. - A similar incident has recurred — which means the previous postmortem did not work. - A near miss occurred. These are the cheapest learning opportunities available and the most commonly skipped. **Do not use this when:** - The incident is ongoing — use `incident-triage`. Writing up an unresolved incident produces a fiction. - The cause is not yet understood — use `production-debugging` first. A postmortem with a guessed cause generates action items that fix nothing. **What this skill assumes:** the incident timeline, the telemetry, and access to the people involved. A postmortem written from logs alone misses the decision-making, which is usually where the useful findings are. ## Operating Procedure 1. **Write the timeline first**, from evidence. Timestamps, what happened, what was observed, what was done. No interpretation yet. 2. **Separate what was known at the time from what is known now.** This is the discipline that makes a postmortem blameless in substance rather than in tone. 3. **Identify contributing factors**, plural. A single root cause is nearly always a simplification that hides the interesting failures. 4. **Analyse detection and response separately from cause.** How long to detect, to en