Incident Postmortem Report

About this template

A document that fixes conditions, not people

This report assumes a blameless postmortem, and the form is built to hold that line. The label above the title reads “Incident postmortem (blameless)”, and there is no cell anywhere for who was at fault. Cause is written in section 2, and what belongs there is not a name but the condition under which anyone would have produced the same outcome. The only place a person appears is in section 3, and there the name is the owner of an action, not the source of the failure. The page runs label, title, gray lead, a four-cell information table, three numbered sections, Key metrics, and Confirmation and approval.

Filling order

1. Fill the four information cells: Incident No., “Started ~ recovered”, Service affected and Severity. They ship as INC-2026-0032, 06-11 14:32 ~ 15:19, Payments API and SEV-2. Do not leave severity as a bare grade – put the reason for that grade in section 1. When the grade moves, the whole response procedure moves with it.
2. Overwrite the gray line under the title with a one-sentence summary of this incident, using words someone would search for after seeing the same symptom.
3. 1. Incident outline and timeline, then 2. Impact and root cause, then 3. Prevention and action due dates.
4. Replace the four values in the Key metrics table.
5. Fill the Confirmation and approval row: Prepared (responders), Reviewed (peer review), Shared (engineering lead).

How the three sections read

• Incident outline and timeline. The time and route of detection – alert or user report – the workaround marked separately from the full recovery, and “The moments where the call could have gone either way, and what was known then”. Put a time in front of each bullet and the section becomes the timeline itself. Write what was known at the time, not what you know now; that distinction is the whole method.
• Impact and root cause. Accounts affected, failed requests and minutes of downtime first, then ask why five times down to the conditions behind it. The last bullet – “Why nothing stopped it automatically” – is the one that earns the meeting. An answer that stops at a person having missed something guarantees the same incident again.
• Prevention and action due dates. Split the actions into detection, mitigation and root fix, give every item an owner and a completion date, and keep the line about checking three months later that it was actually done. Follow-through is where postmortems collapse, and the form says it outright: an action with no owner and no due date is not an action.

The four metric cells

Key metrics is a two-row, four-column table with values on top: 14:32 / Started at, 21 min / Detect & notify, 47 min / Time to recover, 12,000 / Accounts affected. Detect and notify and time to recover are the two you will set targets against, so the next report compares against these same labels – which only works if the whole organization counts the start of an incident the same way. Agree that definition once. Where a number involves estimation, as accounts affected usually does, put the method in section 2 in one line, and give a range rather than a false precision when you cannot count exactly.

Running the review

Do not finish the document and then hold the meeting. Circulate a draft with only the timeline filled in – within a day of the incident closing – and let the responders correct the times. Dig into cause together in the meeting, and set the actions and their dates in the room; actions deferred to afterwards are usually never set. Then complete the approval row and decide where the report is stored and who may read it. If you want the timeline as a table, add a three-column one – time, what happened, action taken – under section 1.

Before you share it

• A person’s or a team’s name in the cause section. This is the single thing the form exists to prevent.
• Finalizing without the responders having checked it. Circulate the draft and settle the facts first.
• Prevention items with no date. Next quarter is not a due date.
• A customer notice that went out but was never recorded here, leaving the external and internal accounts to drift apart.
• Leaving the incident number as INC-2026-0032. Alerts, tickets and this report are tied together by it.