A reviewer should check five things: key incident data was collected, the impact assessment is complete, the cause goes deep enough, the action plan is sized and prioritised properly, and the right stakeholders were told. Add a sixth for tone. An unreviewed postmortem might as well never have existed.
Where the criteria come from
Google's SRE book says teams share the first draft internally and ask senior engineers to assess it for completeness. Its example criteria: was key incident data collected for posterity, are impact assessments complete, was the root cause sufficiently deep, is the action plan appropriate and are bug fixes at the right priority, and did we share the outcome with relevant stakeholders. It also says that to make sure each draft gets reviewed, regular review sessions help, and a reviewed postmortem goes into a repository.
The checklist
| Area | Ask | Red flag |
|---|---|---|
| Data | Are logs, queries and links attached? | A timeline with no evidence |
| Impact | Is there a number, or an estimate with its basis? | "Some customers were affected" |
| Cause | Are there several contributing causes, reaching process or system facts? | One cause that ends at a person |
| Detection | How was it found, and how could it be faster? | Detection not mentioned |
| Actions | One owner, one priority, one ticket each? | "Improve" with no owner |
| Language | Neutral and factual? | Names, adjectives, exclamation marks |
| Context | Can someone outside the team follow it? | Unexplained acronyms |
| Sharing | Who has been told, and is it in the repository? | Shared with the team only |
The Workbook's bad example fails nearly all of these: missing context, missing numbers, empty recovery section, vague actions, four owners, animated language and a limited audience. Even a rough estimate of impact, it says, beats no data.
Steps for the reviewer
- Read it cold, without talking to the author first.
- Mark every place you had to guess. Those are gaps.
- Check the timeline against one independent source, such as a ticket or deploy log.
- Ask whether the causes would still make sense to a new hire.
- Look at the actions. Would completing all of them stop a repeat?
- Leave comments as questions, not verdicts.
- Mark the review status, so the author knows whether to revise or publish.
PagerDuty suggests posting the draft for review by experienced writers about a day before the meeting, which spares the meeting from style issues.
Who should review
Choose someone senior who was not in the incident, and, for security incidents, someone who can judge sensitivity before wider release. For tone checks, see how to spot blame in a draft. For what to withhold from outside readers, see public postmortem for customers.
How Safeguard fits
If a postmortem includes dependency claims, the reviewer can check them against an SBOM. Safeguard's SBOM and dependency scanning supports that, with a free scan at https://gold.safeguard.sh/scan.
Quick check
How long should a review take?
For a typical draft, 20 to 30 minutes of cold reading is enough to find most gaps.
Should the reviewer approve or just comment?
Both. Comments improve the draft and a named approval marks it complete. Atlassian uses named approvers for this.
Sources
- Google SRE book, Postmortem Culture
- Google Site Reliability Workbook, Postmortem Culture
- PagerDuty incident response documentation, postmortem process
- Atlassian incident management handbook, postmortems
Last reviewed: 19 October 2026.
