Run the review within a week, while memories are fresh. The goal is not "whose fault" — it's a written answer to three questions: what happened, why did it take that long to fix, and what stops it recurring. Keep it to one page.
The template
[Date] — [One-line incident title]
Impact: [Who/what was affected, for how long. Numbers if you have them: "~40% of API requests failed for 23 minutes".]
Severity: [Your level, e.g. SEV2]
Timeline
All times [timezone].
- [time] — [First cause event, e.g. deploy, config change, upstream failure]
- [time] — [First detection: alert fired / customer reported — be honest about which]
- [time] — [Response started]
- [time] — [Customers first informed]
- [time] — [Cause identified]
- [time] — [Fix applied]
- [time] — [Resolved confirmed]
What happened
[3–6 sentences, plain English, no blame. A new engineer should understand it.]
What went well / what didn't
- Well: [e.g. "Alert fired within 2 minutes"]
- Didn't: [e.g. "First customer update took 45 minutes"]
Actions
Action Owner Due [Specific and checkable, e.g. "Add heartbeat check on the export worker"] [name] [date]
Rules
- Look at the gaps in the timeline — detection→response and response→customer-informed are where trust is won or lost, and they're usually more fixable than the root cause.
- Three actions with owners beat ten without. An action nobody owns is a wish.
- "Human error" is not a cause. Ask what made the mistake easy and the catch absent.
- Share it — internally always; publicly if customers were affected. A clear post-incident note reads as competence, not weakness.