Post-mortem template

A post-mortem template is a fixed structure a team fills in after something has gone wrong. It sets out what happened, when, why, and what changes next. The structure matters because it stops the review turning into an argument about blame.

A post-mortem template (PMT) is not a pre-mortem template, which shares the same initials. The post-mortem looks backwards at a failure that already happened; the pre-mortem looks forward at one that has not.

It is also not a performance review and not a project closure report. A closure report records what was delivered — a post-mortem explains one specific failure and names the changes that follow from it.

Key takeaways

• A post-mortem template captures what happened, why, and what changes, in a fixed order.
• Timeline first, cause second, actions last, with every action owned and dated.
• Blameless wording keeps people honest — it is the only way to get a real timeline.
• A review with no tracked actions is a diary entry, not a control.

How it works

A post-mortem template works by forcing the same questions in the same order every time. Facts before judgement, judgement before action. That order is what makes two reviews comparable six months apart.

The template is the tail end of incident management. Detection, triage and recovery come first; the review is what turns that episode into a change somebody owns.

Where the template sits is set by your incident management framework, which defines severity levels and says which incidents get a written review at all.

The timeline usually exposes a slow escalation. People saw something odd and waited — which is a process fault rather than a personal one.

When that happens, the fix belongs in the escalation plan rather than in a reminder to be more careful next time.

For software failures the actions often point at test coverage, and defect density is the measure teams watch afterwards to see whether anything actually moved.

Fill the timeline from evidence, not memory. Log entries, chat transcripts and ticket timestamps give you the times; people give you what they believed at each of those times, which is the more useful column.

Separate the cause from the contributing factors. One change broke the service, but the reason nobody noticed for forty minutes is a different finding and needs an action of its own.

Keep the action list short. Three changes that get made beat twelve that get listed, and a review that produces a backlog nobody grooms teaches the team the whole exercise is theatre.

Date every action and name one owner. A shared owner is no owner, and an undated action drifts until the next incident makes it urgent again.

Review the reviews. Reading six months of post-mortems together shows patterns no single document can — the same dependency, the same missing alert, the same weekend.

Publish them widely. A review kept inside the team that caused the failure protects nobody else from repeating it.

Standards bodies treat the review as risk management, not paperwork.

The US National Institute of Standards and Technology published Revision 3 of its incident response guidance in April 2025, superseding the 2012 edition, to help organisations reduce the number and impact of incidents.

Standardising the shape is the point. Executive Order 14028 directed the Department of Homeland Security, through the Cybersecurity and Infrastructure Security Agency (CISA), to produce a standard set of operational procedures for incident response.

CISA issued two playbooks in answer, one covering incidents and one covering vulnerabilities, built on lessons learned from earlier incidents and on industry practice.

Examples

Post-mortem templates turn up wherever failure is expensive and repeatable. Software operations, outsourced service delivery and federal cyber response all run a version, and the sections look remarkably alike across them.

Service outages. A provider running a client’s payment queue writes the review within days, while the timeline is still recoverable from logs and from the people who were awake for it.

Service level breaches. When a contracted target is missed, the review is commercial as well as technical, and its actions reappear in the next governance meeting with owners and dates attached.

Transition failures. When a process moves to a new provider and misses its first month targets, the review has to cover knowledge transfer and staffing as well as systems.

Federal cyber response. US civilian agencies work to the CISA playbooks, which hand every agency the same vocabulary for what happened, what was done and what gets tracked afterwards.

Related terms

• Zero defect rate: the target state the actions from a review are aiming at.
• Defects per million opportunities: a normalised quality measure for comparing processes.
• Incident management: the live response the written review follows.
• Escalation plan: the document that most often changes after a slow review.
• Defect density: the measure that shows whether the actions worked.

FAQ

What is a post-mortem template?

It is a fixed structure for writing up a failure after it happens, covering summary, timeline, impact, contributing factors and actions. Using the same order every time makes reviews comparable.

What is the difference between a post-mortem and a pre-mortem?

A post-mortem examines a failure that already happened. A pre-mortem runs before the work starts and asks the team to imagine the project has failed, then explain why.

Should a post-mortem name individuals?

Name roles and systems, not people. Blameless wording buys you the honest timeline, which is the one part of the document nobody can reconstruct later.

How soon should you run one?

Within a few days, while logs are still retained and memories are fresh. Waiting a month gives you a tidy document and a thin timeline.

What makes a post-mortem useless?

Actions with no owner and no date. If nothing is tracked afterwards, the review is just a record of an opinion.

Find delivery partners who run blameless reviews as standard in the Outsource Accelerator hubs.