Incident post-mortem draft

Draft a blameless post-mortem from these raw incident notes.

Impact: {{impact}}

Raw timeline notes (rough, possibly out of order):
{{timeline_notes}}

Structure:
1. Summary - what happened, impact, and duration, in 2-3 sentences a
   non-technical stakeholder could understand.
2. Timeline - cleaned up and in order, with timestamps, distinguishing
   "what happened" from "what we did about it."
3. Root cause - the actual mechanism, not just "human error" or "a bug" -
   trace it back to the systemic condition that allowed the error/bug to
   cause impact (missing test coverage, no alert for this condition, a
   manual step that should have been automated).
4. What went well - genuinely, not just as a formality - anything that
   limited the blast radius or sped up detection/recovery.
5. Action items - each one specific, owned, and phrased as a system or
   process change, not "be more careful." Mark which are must-do before
   this can recur versus nice-to-have.

Keep it blameless throughout: describe what the system allowed to happen,
not what a person did wrong. If the notes name a specific person's action,
rewrite it in terms of the process/system gap that made that action
possible.

When to use

Right after an incident, while the raw notes and Slack thread are still fresh, to get a structured first draft that the team can correct and fill gaps in rather than starting from a blank page. Not a replacement for the team’s own review - a starting point for it.

Why it works

The blameless framing is the whole point of a post-mortem culture, and it’s easy to lose under deadline pressure when writing from raw notes that naturally read as “so-and-so did X” - explicitly rewriting named actions into system gaps keeps the document useful (people won’t hide information in the next incident if this one felt like a blame exercise) instead of just accurate. Separating “must-do” from “nice-to-have” action items stops a long list of good ideas from diluting the two or three that actually prevent recurrence.

Variations

• Add “This will be shared outside the immediate team - remove any internal system names/jargon that need context” for a post-mortem going to a broader audience or customers.
• Ask for a severity/priority rating suggestion for each action item based on your team’s usual incident-review rubric, if you have one.
• For a near-miss (no customer impact, but could have), adjust “Impact” to describe what almost happened rather than what did - the same rigor applies even when nothing broke.