Incident Postmortem Template: Blameless Postmortem Format

An incident postmortem is a written record of what broke, how long it lasted, what it cost, why it happened and what will stop it recurring. A usable template has seven sections: a one paragraph summary, a timestamped timeline, an impact statement in business units, the contributing causes, what went well and badly during the response, the action items with owners and dates, and the lessons worth keeping. It is blameless when it describes what a person did and the system that made that action reasonable, rather than naming who was at fault.

Most teams write their first postmortem after an outage bad enough that somebody senior asked for one. That is the worst time to be inventing a format. What follows is the structure to copy, the trigger rule for deciding which incidents get one, and the part that quietly determines whether the document is worth anything: where the timeline comes from.

The incident postmortem template

Seven sections, in this order. The order matters, because a reader who stops after two minutes should already have the summary, the duration and the impact.

Two fields belong at the top of the document as metadata rather than prose: the incident severity and the total duration, measured from first failure to full recovery. Those are the two numbers anyone will want to sort or compare on later, and burying them inside a paragraph makes a year of postmortems unsearchable.

What is a blameless postmortem?

A blameless postmortem describes what each person did, what information they had at the time, and why their action was reasonable given that information, without assigning fault to individuals. The premise is that engineers acting sensibly on incomplete information is the normal case, so an incident that a reasonable person could cause is a system problem rather than a personnel problem. Naming the person ends the investigation early, because the apparent cause has been found.

In practice the difference is a sentence-level habit. "An engineer ran the migration against production by mistake" invites the reader to stop there. "The staging and production database URLs differ by one character, and the deploy tool defaults to the last used target, so running the migration against production required no confirmation step" points at four things you can actually change. Same event, and only one version leaves you with work to do.

The practical test is whether people volunteer the parts that make them look bad. If the person closest to the incident is writing the document and they include the detail that they dismissed the first alert, the culture is working. If postmortems read like legal filings, they are being written defensively and every one of them is missing its most useful facts.

When should you write a postmortem?

Write one whenever an incident consumed a meaningful share of your error budget, breached a customer commitment, required manual intervention to recover, or surprised you. The Google SRE workbook makes the first of those a hard rule in its example error budget policy: an incident that consumes more than 20% of the error budget over a four week window requires a postmortem, and that postmortem must contain at least one P0 action item addressing the cause.

That rule is worth adopting because it removes the argument. Rather than debating whether an outage was "bad enough", you calculate what it cost. At a 99.9% target over 30 days the budget is 43 minutes 12 seconds, so the 20% threshold is about 8 minutes 38 seconds of downtime. At 99.99% the whole month is 4 minutes 19 seconds and the threshold is 52 seconds, which means almost any real incident qualifies. You can work out the number for your own target with the error budget calculator, and if the underlying concept is new, error budgets in SRE covers where the budget comes from.

The mirror image of that rule matters too. If you are writing postmortems for every transient blip, you will stop writing them properly within a month. Set a threshold, apply it consistently, and let the small stuff be a ticket.

The timeline is the part that fails

Every other section can be reconstructed from memory. The timeline cannot, and it is the section that determines whether the document supports any real conclusion. Three timestamps carry almost all the value:

• First failure. When the service actually stopped working, not when it was noticed.
• First detection. When your monitoring recorded a failed check.
• First acknowledgement. When a human began working on it.

The gap between the first two is your detection delay, and it is the number teams most often cannot fill in. An outage that begins one second after a check runs stays invisible until the next one fires, so the worst case detection delay is one full check interval and the average is half of one. At 5 minute checks your timeline has a 5 minute error bar on its most important entry, and every duration in the impact section inherits that uncertainty. At 30 second checks the same document can state when things broke rather than estimating it.

This is also the honest reason the two numbers should be reported separately. "We were down for 22 minutes" and "we were down for 22 minutes, and we knew about it for 4 of them" describe the same outage and imply completely different work. The first sounds like an infrastructure problem. The second says most of the damage was detection, which is usually the cheapest thing on the list to fix. Where none of the timestamps exist, reconstructing downtime history after the fact covers which surviving sources can bracket an outage, and what each of them can and cannot prove.

Writing the impact section

Impact is where the postmortem stops being an engineering document and starts being readable by the rest of the company, so write it in units the business already uses. Failed requests and error rates are the engineering view. Orders not placed, signups lost, support tickets opened, refunds issued and SLA credits owed are the version that gets an action item funded. Teams that already track support and billing operations in one place can usually pull the ticket and refund counts for the outage window in a few minutes, and those two numbers do more to justify reliability work than any latency chart.

Be specific about who was affected and who was not. "All users in the EU region could not complete checkout for 18 minutes; browsing and login were unaffected" is a sentence somebody can act on. If a fraction of traffic failed rather than all of it, say the fraction, because a 3% error rate and a total outage produce very different conclusions about redundancy.

Action items that actually get done

An action item needs an owner who is a person, a priority that competes with other work, and a date. Anything phrased as an intention will still be open at the next incident. The useful split is between fixes that prevent the cause and fixes that reduce the impact, because the second kind is usually faster to land and pays off across incidents you have not had yet.

If a postmortem produces only prevention items, the response review section was skipped. Almost every incident contains at least one lesson about how quickly the team found out and how quickly they could undo it, and those are the items that compound.

Who should write the postmortem?

The person closest to the incident, usually whoever led the response, with review from someone who was not involved. The responder has the context that never made it into chat, and the outside reviewer catches the assumptions that feel obvious from inside. Handing the writing to a manager who was not there produces a document that is accurate about what happened and empty about why it was hard.

Write it within a few days while the details are still recoverable, and hold a short review meeting rather than circulating it silently. The meeting is where the disagreements about contributing causes surface, and those disagreements are usually the most valuable content in the whole exercise.

How long should a postmortem be?

One to three pages for most incidents. Long enough that the timeline is complete and the causes are specific, short enough that people read it. A postmortem that runs to ten pages is usually compensating for a thin timeline with narrative. If yours are consistently long, the fix is almost always better instrumentation rather than better writing.

What is the difference between a postmortem and an incident report?

An incident report is usually the outward facing summary, written for customers or auditors, covering what happened and what you are doing about it. A postmortem is the internal engineering document, and it contains the parts you would not publish: the alert that was ignored, the runbook that was wrong, the dependency nobody knew existed. Many teams write the postmortem first and derive the customer-facing note from its summary and impact sections, which is the right order. Publishing that summary on a status page closes the loop with the customers who noticed.

Where to start

Copy the seven sections into a document template today, agree an error budget threshold that triggers one, and make sure your monitoring can supply the first two timestamps. The template is the easy part. The detection timestamp is the part that has to exist before the incident, and it is the reason most first postmortems have a timeline that begins with "a customer emailed us". If you want to see how quickly your own stack surfaces a failure right now, the four layer down checker shows which of DNS, TCP, TLS and HTTP is answering, and SLA monitoring keeps the record that a future timeline will need.