incident-postmortem-report

Incident Post-Mortem Report

Guide the user through producing a blameless, audit-ready post-mortem suitable for engineering leadership, compliance, and future incident prevention.

Instructions

Phase 1: Scope and audience

1. Confirm what incident is in scope (ticket ID, time window, service, or free-text summary).
2. Identify audience (internal engineering only vs. includes executives or customers) and adjust depth of business impact language.
3. List facts already known vs. gaps that need research (logs, metrics, deploys, comms).

Phase 2: Structure the report

Use the sections below in order unless the organization mandates a different template. Fill each section with concrete data; avoid vague statements.

1. Executive summary — 2–4 sentences: what broke, who was affected, how long, current status.
2. Impact — Quantify: duration, error rates, revenue/users affected if known, SLA breach yes/no.
3. Timeline — UTC timestamps, short event labels. Include detection, escalation, mitigation, full recovery.
4. Root cause — Single primary cause, explained clearly. Use 5 Whys or equivalent if helpful.
5. Contributing factors — Environment, process, tooling, or communication issues that amplified impact (not blame).
6. What went well — Detection, runbooks, teamwork, rollback, comms.
7. What went wrong — Gaps in monitoring, deploy process, testing, on-call routing, documentation.
8. Corrective actions — Short-term fixes with owners and dates.
9. Preventive actions — Longer-term hardening (tests, SLOs, chaos, capacity).
10. Lessons learned — 2–5 bullet takeaways for the org.
11. References — Links to incidents, PRs, dashboards, chat threads (no secrets).

Phase 3: Tone and quality bar

• Blameless: describe systems and processes, not individuals.
• Specific: numbers, tool names, versions, ticket keys.
• Actionable: every action item has an owner and a target date when possible.

Output Format