What Is a Postmortem?

Last verified on Nov 8, 2026.

A postmortem is a written record of an incident: what the impact was, what people did to mitigate and resolve it, the root causes, and the follow-up work to stop a repeat. Google's SRE book defines it that way and adds the purpose: make sure the incident is documented, the contributing causes are understood, and effective preventive actions are in place.

The postmortem is the document. Root cause analysis is one technique you use to fill it in.

When to Write One

Define the criteria before an incident so nobody debates it at 3 a.m. Google lists these common triggers:

• User-visible downtime or degradation beyond a threshold
• Data loss of any kind
• On-call intervention such as a release rollback or rerouting traffic
• A resolution time above some threshold
• A monitoring failure, which usually means someone found the problem by hand

Any stakeholder can also ask for one. Writing is not free, so the criteria keep the effort aimed at events worth learning from.

What Goes in It

Google's example postmortem uses these fields:

If the Detection field says a customer told you, the detection guides on novel events and latency spikes show what to alert on instead.

Keep the timeline in UTC and quote log lines or alert names as evidence:

14:02 UTC  Deploy of checkout v212 finishes
14:09 UTC  Error rate on /pay crosses 5%; page sent to on-call
14:15 UTC  On-call acknowledges, starts rollback
14:24 UTC  Rollback complete; error rate back under 0.1%

This is an example, not a real incident.

What Blameless Means

Blameless does not mean unaccountable. Google's wording is that a blameless postmortem focuses on contributing causes without indicting any individual or team, and assumes everyone involved had good intentions and did the right thing with the information they had. The reason is practical: if people expect punishment, they stop bringing problems to light. AWS lists focusing on blame instead of root cause as an anti-pattern for the same reason.

The test is the question you ask. "Why did the engineer run that command?" ends the investigation. "Why did the system let that command touch production, and why did the prompt not warn about it?" produces an action item.

Writing Good Action Items

Google's postmortem workbook is specific about what makes action items weak: mostly mitigative with nothing preventive, all at equal priority, vague verbs like "improve" or "make better", and no tracking ticket. It also notes that changing automated systems is more dependable than asking humans to be more careful. Write items you can verify as done, give each an owner and a ticket, and rank them.

Review and Publish

The SRE book's review questions are a good checklist: was the key incident data collected, are the impact assessments complete, was the root cause sufficiently deep, is the action plan appropriate and at the right priority, and was the outcome shared with stakeholders. It also says an unreviewed postmortem might as well never have existed, so schedule the review. Publish promptly, while people still remember.

Your on-call engineers are the best source for the timeline, and the runbook that did or did not help is often an action item. For response metrics to track, see MTTR.

Evidence from Sazabi

Sazabi, an AI-native observability and security platform, keeps an event history on every issue: created, resolved, ignored, muted, unmuted, and updated, each with a timestamp and the actor. That history is a convenient starting point for the timeline section, alongside the log searches you ran during the incident.