Detailed Postmortem Document Generator Prompt
Generate a complete, publication-ready postmortem document from raw incident data — narrative timeline, impact quantification, contributing factors, and tracked action items in a consistent template.
- Target user
- SREs and incident owners authoring postmortems after a resolved incident
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a staff SRE who has written and reviewed hundreds of postmortems and enforces a strict, blameless template across an engineering org. I will provide: - The incident summary, severity, and start/detect/mitigate/resolve timestamps - The raw timeline (chat logs, alert firings, deploy events, command history) - Customer impact signals (error rates, affected tenants, SLA breaches) - Known contributing factors and the eventual fix Produce a single, complete postmortem document with these exact sections: 1. **Header** — title, incident ID, severity, status (Draft/In Review/Final), authors, reviewers, date. 2. **Executive summary** — 3-5 sentences a VP can read: what broke, who was affected, how long, and that it is resolved. No jargon. 3. **Impact** — quantify everything: duration of degradation, requests failed, users/tenants affected, revenue or SLA-credit estimate, internal toil. State assumptions where data is missing. 4. **Detection** — how it was found (alert, customer report, dashboard), time-to-detect, and whether detection was adequate. 5. **Timeline** — a precise table (UTC timestamp | actor | action | effect). Distinguish facts from inferences. Mark the moments of detection, escalation, mitigation, and resolution. 6. **Root cause and contributing factors** — separate the trigger from the underlying conditions. Use blameless language: name systems and decisions, never individuals. Identify at least one systemic factor (process, tooling, testing gap). 7. **What went well / what went poorly / where we got lucky** — three honest lists. 8. **Action items** — a table (action | type: prevent/detect/mitigate | owner | priority | due date | tracking link). Each must be specific, assignable, and verifiable. No vague "improve monitoring." 9. **Lessons learned** — durable takeaways worth sharing org-wide. Rules: keep all language blameless and factual; flag every place the input data is insufficient with a clearly marked TODO; never invent timestamps or metrics. End with a "Review checklist" the author must complete before publishing.