Post-Incident Review Template

Postmortem doc published with timeline, impact, root cause, contributing factors, what worked, corrective actions. Stakeholder review held. Public version (P1) sanitized and published.

Before you start

Postmortem template approved (blameless, structured)
Incident timeline data accessible
Stakeholder review process
Incident timeline (start, escalation, resolution)
On-call notes and chat transcripts
Customer impact data (count, ACV, support tickets)

The steps

Compile the timeline — Build a minute-by-minute timeline from when monitoring fired or customer reported, through escalation, diagnosis, attempted fixes, and resolution. Use UTC and include who did what at each step.
Document customer impact — How many customers affected? Which features were affected? How long was the impact? What was the financial/reputational cost? Numbers, not adjectives.
Identify root cause — Use 5-Whys or similar. The root cause is rarely the immediate trigger. 'Database fell over' is the trigger; 'we didn't have alerting on disk usage' is closer to the root cause.
Identify contributing factors — Beyond root cause: what amplified the incident? Slow detection, unclear runbook, on-call confusion, missing monitoring, recent change without rollback plan. List separately from root cause.
Identify what worked — Postmortems should celebrate good response, not just failures. Did monitoring fire correctly? Did escalation work? Did the customer-comms loop close fast? List what worked so it gets reinforced.
Define corrective actions — For each contributing factor, define an action: owner, ETA, expected outcome. Actions must be concrete and assigned, not 'we should consider'. 1-3 high-impact actions beats 10 vague ones.
Review with stakeholders and publish — Hold a 30-minute review meeting with engineering, ops, and impacted teams. Refine based on input. Publish in the postmortem repository. For P1: publish externally (sanitized version) for customer trust.

If it goes wrong

Postmortem turns into blame, team becomes defensive

Reframe immediately. 'We had a process gap that allowed this' beats 'Sarah missed it'. If the team learns to hide incidents, postmortem culture is broken.

Corrective actions never get done

Track action items in the same tracker as feature work. Post a quarterly 'postmortem actions completion' metric. Without follow-through, postmortems are theater.

Same root cause keeps appearing

When root cause repeats, the corrective action wasn't sufficient or wasn't done. Escalate to leadership: this is structural, not incidental.

All OpenLabor playbooks