Most postmortems produce a document nobody reads and actions nobody owns. This one forces the three things that actually reduce repeat incidents: a timeline built from timestamps rather than memory, contributing factors stated without naming a person, and action items with an owner and a date.
Fill the timeline from logs, not memory. Work from monitoring, deploy history, and chat transcripts. Record the time each event actually occurred and, separately, the time someone noticed. The gap between those two columns is usually the most useful number in the document.
Write contributing factors, not a root cause. Serious incidents rarely have one cause. List every condition that had to be true for this to happen. If a factor names a person, rewrite it to name the system that allowed the action.
Separate detection from prevention. For each action item, mark whether it stops the incident recurring or shortens the time to notice it. Teams over-index on prevention; the detection column is what cuts severity next time.
Review action items at the next incident review. An action item with no due date is a wish. Carry the open items into your next review and close or re-own them explicitly.
Here's a preview. Unlock the free download to get all 6 sections (5 more below).
Fill this last. It should read as a complete account on its own.
More free templates IT teams use alongside this one.
A rota is more than a list of names against dates. This template covers the parts that cause real pages to go unanswered: who the secondary is, what happens when nobody acknowledges, and what the outgoing engineer must hand over.
Most severity matrices fail in the one moment they matter: at 02:00, when a tired engineer has to decide whether to wake anyone. This one is written so the level is readable off customer impact alone: no judgement call about root cause, no guessing how bad it might get.
Security incident response plans are usually written for an auditor and discovered to be unusable during the first real incident. The sections that matter are the ones you read in the first hour: who decides, who to call, and what not to touch.
A summary a non-engineer can follow, a timeline built from logs, the contributing factors that made the incident possible, and action items with named owners and due dates. Time to detect and time to mitigate should be recorded separately: they point at different problems.
One that describes what the system permitted rather than who made a mistake. It exists for a practical reason: engineers who expect blame report less detail and report it later, which is exactly when you need the information most.
Draft the timeline within 24–48 hours while logs and memory are fresh, then review as a group within a week. Leaving it longer reliably produces a thinner timeline.
