What should a postmortem template always include?

Four sections cover it: a timeline of what happened and when, the blast radius showing who and what was affected, the contributing factors that let the incident happen, and action items with a named owner and a date. Anything beyond these four tends to turn into padding that nobody reads after the incident is closed.

Why does a timeline matter more than a root cause?

A single root cause is usually a simplification, because most incidents happen when several small conditions line up at once. A timeline forces you to write down every one of those conditions in order, which is what lets you find the earliest point where a different action would have stopped the incident, not just the last domino that fell.

What is blameless framing, and why does it work?

Blameless framing means the postmortem looks for the conditions that let a person make a reasonable-seeming choice that turned out wrong, instead of asking who to blame. It works because a person who expects to be blamed will describe events in a way that protects themselves, and that version of events is usually missing the detail that would actually prevent a repeat.

Does blameless mean nobody is accountable?

No. Blameless separates two different questions: what happened, which should be judged without blame so the facts come out complete, and what changes as a result, which is where accountability lives. The team or company commits to specific fixes with owners and dates, and that commitment is the accountability, not a finding of individual fault.

How does a postmortem change when AI-generated code was involved?

The timeline needs one more fact at the point the change was introduced: who reviewed the generated code, and what automated check ran against it before it shipped. The four sections stay the same, but "a person wrote this and made an error" is replaced by a more specific question: did a check exist for this failure mode, and if not, why not.

Who should attend a postmortem review meeting?

Everyone who touched the incident during response, plus anyone who owns a system in the blast radius, even if they were not paged. The person who made the change that triggered the incident should be in the room, because their account of what they saw at the time is the most valuable input in the document, not the most awkward one.

How soon after an incident should the postmortem be written?

Write the draft within one to two business days, while people still remember what the monitoring dashboards showed and what they were thinking at each step. Waiting a week or more means the account gets rebuilt from memory and logs alone, and the reasoning behind decisions, which is often the most useful part, gets lost.

What makes an action item useless?

An action item with no owner or no date is a wish, not a commitment, and it is the single most common reason postmortem findings never get fixed. "Improve monitoring" is not an action item; "add a paging alert on queue depth above 500, owned by the platform team, done by the next sprint" is.

Should a postmortem be shared outside the team that owned the incident?

Yes, within the company. Other teams often run the same kind of system or made the same kind of assumption, and a postmortem that stays inside one team's folder only prevents that one team from repeating the mistake. Wide, low-friction sharing is part of what makes the blameless approach pay off.

What is the most common mistake in a first postmortem template?

Making it about the person who pushed the change instead of the system that allowed the change to cause damage. A close second is skipping the blast radius section, which means nobody has an honest answer for how many customers or downstream systems were actually affected, only a guess based on what got noticed.

What a good incident postmortem template looks like: Reveneau

An incident postmortem is not a report you write because someone asked for one. It is the only document a team produces after things go wrong that is actually read by the people it is meant to help, if it is built right. Most are not built right. They get written fast, filed away, and never opened again, because the template asked the wrong questions or asked them in a way that made people defensive instead of specific.

When we scope a build for a client, we look at how they run postmortems before we look at almost anything else in their engineering process. It tells us more about how a team will behave under pressure than their architecture diagrams do. A team with a clear, blameless postmortem habit tends to fix the same problem once. A team without one fixes the symptom, repeatedly, for years.

Here is what a postmortem template needs to do its job: four sections, in order, each earning its place.

1. The timeline

The timeline is the spine of the whole document. It is a plain, chronological list of what happened, in the order it happened, with timestamps. Not what someone thinks caused the incident. Not who is responsible. Just: at this time, this was observed; at this time, this action was taken; at this time, service was restored.

Resist the urge to summarize here. Write "14:02 UTC: deploy of payment-service v2.14 completed" and "14:09 UTC: error rate on /checkout climbs from 0.1% to 12%" as separate lines, even though the connection between them looks obvious in hindsight. The value of a full timeline is that it often reveals an earlier point where the incident could have been caught, one that the summary version would have skipped past.

A timeline with real timestamps also does something a narrative summary cannot: it lets a second reader, someone who was not in the incident channel, independently check whether the response was as fast as everyone remembers it being. Memory compresses time under stress. The clock does not.

2. Blast radius

Blast radius answers one question precisely: who and what was actually affected, and for how long. Not "the checkout flow was degraded." Instead: which regions, which percentage of requests, which customer segment, over what exact duration, and whether any data was lost or corrupted as opposed to just delayed.

This section is often the weakest part of a postmortem, because by the time the write-up happens, the team already moved on to the fix and nobody wants to go back and pull the exact numbers. That is exactly why it matters. Without a real blast radius, the severity of an incident gets set by how loud the complaints were, not by what actually happened, and that miscalibrates which incidents get investigated the deepest.

Blast radius also decides who needs to see the postmortem. An incident that touched one internal dashboard gets a different distribution list than one that touched customer billing.

3. Contributing factors

This is where most templates get the framing wrong, and it is worth spending the most care on. "Root cause" implies one single failure, traced back to one single point. Real incidents are rarely that. They are usually several ordinary conditions stacking on top of each other: a monitoring gap that had existed for months, a deploy that happened to land during a traffic spike, a retry policy that made a small backend slowdown into a full outage.

List every contributing factor separately, and resist collapsing them into one sentence. "The deploy caused the outage" is a summary, not an analysis. "The deploy removed a rate limit that had been silently protecting a downstream service from its own retry storm, and nobody knew the rate limit was doing that job" is a contributing factor a team can actually act on.

This is also the section where blameless framing earns its keep, which is the whole reason the practice exists in engineering. The Google Site Reliability Engineering book's chapter on postmortem culture states the goal directly: a postmortem should identify contributing causes without singling out any individual or team for blame, because you cannot fix a person, but you can fix a system. When someone believes their name is going to be attached to a mistake in a document that gets circulated widely, they describe events defensively. They round the timeline in their own favor. They leave out the moment they hesitated or guessed. A team that has made blameless framing real, not just stated as policy, gets a different answer: "I saw the alert, decided it looked like the usual noise, and did not check further," written by the person it happened to, because they trust that writing it down will lead to a better alert, not a bad mark against them.

That trust is not automatic. It gets built by what happens after the first few honest postmortems, when the follow-up is genuinely "let's fix the alert" and not a quieter version of blame.

4. Action items, with owners and dates

An action item with no owner is not an action item. It is a hope. "Improve monitoring on the payment queue" will still be an open bullet point in the same document a year later, because nobody's name is next to it and nobody's calendar has a date on it.

Every action item needs three things: a specific change, a single owner (a team is acceptable, a name is better), and a date. "Add a paging alert when queue depth exceeds 500 messages, owned by the platform team, shipped before the next release" is something you can check on later and something that either happened or did not.

Keep the list short. Five well-specified action items that actually get done outrun twenty vague ones that get triaged into a backlog and forgotten. If the contributing factors section surfaced ten possible fixes, that is a sign to prioritize, not to write ten action items.

What changes when generated code was involved

The four sections do not change. What changes is one specific question the timeline and the contributing factors sections both need to answer: at the point the problematic change was introduced, who reviewed it, and what automated check ran against it before it shipped.

This matters because AI-assisted development moves the failure point. The 2025 DORA State of AI-assisted Software Development report, based on survey responses from nearly 5,000 technology professionals, found that AI coding tools measurably increase individual output (21% more tasks completed, 98% more pull requests merged) while organization-level delivery metrics stay flat. The report's own warning is direct: speed without stability is just faster chaos. More code moving through the pipeline faster means more chances for a subtle mistake to reach production before anyone reads it closely enough to catch it.

There is a second effect worth naming plainly in the contributing factors section, because it is counterintuitive and easy to miss. A randomized controlled trial from METR found that experienced developers using AI tools on real tasks took 19% longer than developers working without them, and afterward estimated that the tools had made them 20% faster. If a postmortem's timeline shows a reviewer moving quickly through a generated diff, "they were rushed" is not automatically the honest contributing factor. "The tool created a feeling of speed that did not match the actual time spent reviewing" might be closer to true, and it points at a different fix: a slower, more structured review step, not a faster one.

This is why the way a team catches problems before they ship matters as much as how it writes them up afterward. In the work we do, the postmortem for an incident involving generated code always checks one thing first: did an eval, an automated check written from the specification, exist for this failure mode. If it did and it passed anyway, the check was wrong and that is a contributing factor to fix directly. If no check existed, that gap belongs in the action items with an owner and a date, the same as any other fix. Either way, the question resolves to the team's process, not to whether a person or a model wrote the line that failed.

A postmortem template does not prevent incidents. It decides whether the same incident happens once or keeps happening under a different name. The four sections and the blameless framing exist for the same reason: to get the true account onto the page instead of the comfortable one, so the fix that gets written down is the fix that actually holds.

Sources

Google SRE Book: Postmortem Culture: Defines blameless postmortem practice and the reasoning that a postmortem should identify contributing causes without blaming individuals.
DORA 2025 State of AI-assisted Software Development Report: Source for the finding that AI tools increase individual task and pull-request throughput while organizational delivery metrics stay flat.
METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developers: Source for the randomized trial finding that AI tool use made experienced developers 19% slower while they perceived themselves as 20% faster.