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
- Confirm what incident is in scope (ticket ID, time window, service, or free-text summary).
- Identify audience (internal engineering only vs. includes executives or customers) and adjust depth of business impact language.
- 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.
- Executive summary — 2–4 sentences: what broke, who was affected, how long, current status.
- Impact — Quantify: duration, error rates, revenue/users affected if known, SLA breach yes/no.
- Timeline — UTC timestamps, short event labels. Include detection, escalation, mitigation, full recovery.
- Root cause — Single primary cause, explained clearly. Use 5 Whys or equivalent if helpful.
- Contributing factors — Environment, process, tooling, or communication issues that amplified impact (not blame).
- What went well — Detection, runbooks, teamwork, rollback, comms.
- What went wrong — Gaps in monitoring, deploy process, testing, on-call routing, documentation.
- Corrective actions — Short-term fixes with owners and dates.
- Preventive actions — Longer-term hardening (tests, SLOs, chaos, capacity).
- Lessons learned — 2–5 bullet takeaways for the org.
- 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
Deliver the post-mortem as Markdown using this skeleton:
# Post-Mortem: [short title]
| Field | Value |
|-------|-------|
| **Status** | Draft / Final |
| **Date** | YYYY-MM-DD |
| **Author(s)** | |
| **Incident ID(s)** | |
## Executive summary
[2–4 sentences]
## Impact
- **Duration:** …
- **Scope:** …
- **Customer / business impact:** …
## Timeline (UTC)
| Time | Event |
|------|-------|
| … | … |
## Root cause
[Clear explanation]
## Contributing factors
- …
## What went well
- …
## What went wrong
- …
## Action items
| Action | Type (corrective / preventive) | Owner | Target date |
|--------|--------------------------------|-------|-------------|
| … | … | … | … |
## Lessons learned
- …
## References
- …
Examples
- "Write a post-mortem for yesterday's API outage from 14:00–16:30 UTC affecting checkout."
- "Draft a blameless incident review for INC-4521; we rolled back service X at 09:45."
- "Turn these notes from the war room into a formal post-mortem document."
Guidelines
- If information is missing, state assumptions explicitly or list open questions instead of inventing facts.
- Align severity and customer-impact language with the org’s incident taxonomy if the user provides it.
- Do not include credentials, full PII, or unreleased security details in the body; redact or summarize.
- Prefer UTC for all times unless the user requests a specific timezone.
1---2name: incident-postmortem-report3description: Produce a thorough incident post-mortem report after an outage or customer-impacting event. Covers executive summary, impact, detailed timeline, root cause, contributing factors, corrective and preventive actions, and lessons learned. Use when the user asks to write, draft, or complete a post-mortem, blameless review, or incident review document.4---56# Incident Post-Mortem Report78Guide the user through producing a **blameless**, audit-ready post-mortem suitable for engineering leadership, compliance, and future incident prevention.910## Instructions1112### Phase 1: Scope and audience131. Confirm **what incident** is in scope (ticket ID, time window, service, or free-text summary).142. Identify **audience** (internal engineering only vs. includes executives or customers) and adjust depth of business impact language.153. List **facts already known** vs. **gaps** that need research (logs, metrics, deploys, comms).1617### Phase 2: Structure the report18Use the sections below in order unless the organization mandates a different template. Fill each section with concrete data; avoid vague statements.19201. **Executive summary** — 2–4 sentences: what broke, who was affected, how long, current status.212. **Impact** — Quantify: duration, error rates, revenue/users affected if known, SLA breach yes/no.223. **Timeline** — UTC timestamps, short event labels. Include detection, escalation, mitigation, full recovery.234. **Root cause** — Single primary cause, explained clearly. Use **5 Whys** or equivalent if helpful.245. **Contributing factors** — Environment, process, tooling, or communication issues that amplified impact (not blame).256. **What went well** — Detection, runbooks, teamwork, rollback, comms.267. **What went wrong** — Gaps in monitoring, deploy process, testing, on-call routing, documentation.278. **Corrective actions** — Short-term fixes with owners and dates.289. **Preventive actions** — Longer-term hardening (tests, SLOs, chaos, capacity).2910. **Lessons learned** — 2–5 bullet takeaways for the org.3011. **References** — Links to incidents, PRs, dashboards, chat threads (no secrets).3132### Phase 3: Tone and quality bar33- **Blameless:** describe systems and processes, not individuals.34- **Specific:** numbers, tool names, versions, ticket keys.35- **Actionable:** every action item has an owner and a target date when possible.3637## Output Format3839Deliver the post-mortem as **Markdown** using this skeleton:4041```markdown42# Post-Mortem: [short title]4344| Field | Value |45|-------|-------|46| **Status** | Draft / Final |47| **Date** | YYYY-MM-DD |48| **Author(s)** | |49| **Incident ID(s)** | |5051## Executive summary52[2–4 sentences]5354## Impact55- **Duration:** …56- **Scope:** …57- **Customer / business impact:** …5859## Timeline (UTC)60| Time | Event |61|------|-------|62| … | … |6364## Root cause65[Clear explanation]6667## Contributing factors68- …6970## What went well71- …7273## What went wrong74- …7576## Action items77| Action | Type (corrective / preventive) | Owner | Target date |78|--------|--------------------------------|-------|-------------|79| … | … | … | … |8081## Lessons learned82- …8384## References85- …86```8788## Examples8990- "Write a post-mortem for yesterday's API outage from 14:00–16:30 UTC affecting checkout."91- "Draft a blameless incident review for INC-4521; we rolled back service X at 09:45."92- "Turn these notes from the war room into a formal post-mortem document."9394## Guidelines9596- If information is missing, **state assumptions explicitly** or list **open questions** instead of inventing facts.97- Align severity and customer-impact language with the org’s incident taxonomy if the user provides it.98- Do not include credentials, full PII, or unreleased security details in the body; redact or summarize.99- Prefer **UTC** for all times unless the user requests a specific timezone.
caipe-io