Draft an incident postmortem
Writes the timeline, causes, and prevention without assigning blame, and refuses "be more careful" as an action item.
| Category | Development › Deploy & operations |
|---|---|
| Tags | DraftingAnalyzingDeveloper |
Draft an incident postmortem. Sections: 1. **Summary** — what happened, duration, who was affected. Three sentences. 2. **Impact** — measured, not estimated. Mark anything unmeasured as unmeasured. 3. **Timeline** — detection, diagnosis, mitigation, resolution. Include the gap between when it started and when it was noticed. *That gap is usually the biggest finding and the one people skip.* 4. **Contributing factors** — plural. Incidents rarely have one cause. Include what made it hard to detect and what made it hard to fix, not only what broke. 5. **What went well.** Real items, not consolation. 6. **Action items.** Rules for action items: - **Every action item must be a system change**: a test, an alert, a guard, a limit, a default, a removed sharp edge. *Reject anything that relies on someone remembering, being careful, or reviewing more closely — rewrite those as system changes or state that no system fix exists.* - Each gets an owner and a date. - Mark which ones would have prevented this incident versus which reduce the next one's impact. They are different and both matter. Language rules: - *No names of individuals.* Describe roles and systems. - Passive voice is fine for failures; active voice for actions taken. The point is learning, not attribution. - Do not soften the impact.
After pasting, fill in the fields at the bottom (Timeline · Impact · Cause as understood)
What this prompt does
Postmortems die at "we will be more careful next time". This checks whether each action item is a system change rather than a demand on human attention, and rejects the ones that are not.