Incident Postmortem Template
A blameless postmortem structure that produces decisions rather than a narrative — timeline, contributing conditions, and actions with owners and dates.
Reviewed 2026-09-21 · next review 2027-09-21
WHEN TO USE IT
After any incident that reached users, breached an internal objective, or surprised the people responding. Also use it after a near miss: the learning is identical and the pressure is lower. Do not use it for routine alerts that behaved exactly as designed.
Write it within a week, while people still remember what they believed at the time — which is the part that decays fastest and matters most.
HOW TO USE IT
One owner drafts, the responders review, and the review meeting exists to find missing contributing conditions rather than to approve prose. Keep it blameless in the strict sense: describe what made the action reasonable to the person taking it. "Operator error" is never a cause; it is a description of where the system's assumptions met a human.
The test of a finished postmortem is not that it explains the incident. It is that someone who was not there can say what will be different.
THE TEMPLATE
# Incident: <short description>
Status: draft | in review | final
Severity: <your scale> Duration: <detection → resolution>
Author: <name> Reviewers: <names>
## Impact
Who was affected, how many, for how long, and what they could not do.
State the user-visible effect before the technical one.
## Timeline
| Time (UTC) | Event | Who knew |
|---|---|---|
| 00:00 | <trigger> | |
| 00:00 | <detection — and by what> | |
| 00:00 | <first mitigation attempt, and why that one> | |
| 00:00 | <resolution> | |
## What we believed at the time
The working theory at each decision point, and what made it reasonable.
This is the section that produces the best actions.
## Contributing conditions
Not "the cause". List the conditions that had to be true together.
For each: was it known? was it accepted? by whom?
## What went well
Name it explicitly — the controls that worked are the ones to protect.
## Actions
| Action | Owner | Due | Ticket |
|---|---|---|---|
Each action must be something a person can finish. "Improve monitoring"
is not an action; "alert on replication lag > 30s, owned by X" is.
## Detection gap
How long between the trigger and someone knowing, and what would have
shortened it.
ADAPTING IT
Small teams can drop the reviewer list and merge "what we believed" into the timeline. Regulated environments usually need an approval signature and a retention period — add them at the top rather than the end, so the compliance need does not push the learning content down the page.
Resist adding fields you will not fill in. A postmortem template that is 60% empty in practice teaches people the form is optional. See /incidentops for the surrounding process and /checklists for the response checklists this feeds.