Measure postmortems by what they cause: how many were completed and reviewed, how fast actions close, whether similar incidents recur, and what the team says about the process. Do not use raw incident counts as a score, because fewer reports can mean people stopped speaking up.
What published guidance suggests
Google's SRE book recommends asking for feedback on postmortem effectiveness. It surveys teams with questions such as: is the culture supporting your work, does writing a postmortem entail too much toil, what practices does your team recommend, and what tools would help. The Workbook adds that a cross-functional group of developers, SREs and leaders meets monthly to review the process and the template, and that postmortem completion and review should be tracked.
Atlassian goes further on actions: it built reporting to count how many incidents of each severity have not had their root causes fixed through priority actions, and managers review that list regularly.
A starter scorecard
| Measure | What it tells you | Watch out for |
|---|---|---|
| Triggered incidents with a postmortem | Is the process used? | Gaming by downgrading severity |
| Postmortems reviewed | Is anyone reading them? | Rubber stamping |
| Days to publish | Is learning timely? | Rushing quality |
| Priority actions closed in target window | Do fixes happen? | Closing tickets without effect |
| Incidents with an open root cause fix | Backlog of known risk | Needs an owner |
| Repeat incidents | Do lessons stick? | Needs consistent tags |
| Team survey result | Is the culture safe? | Small samples |
For the repeat measure, you need consistent labels. See how to tag past incidents.
Measures to avoid
- Incident count as a goal. Pushing the count down encourages hiding. A rise in reported near misses may be good news.
- Mean time to resolve alone. It mixes very different events. Our post on MTTR for incident response versus vulnerability remediation explains the pitfall.
- Number of actions created. PagerDuty advises against creating too many tickets. Quality beats volume.
Steps to roll it out
- Pick three measures from the table: one for process (reviewed), one for follow through (actions closed), and one for outcome (repeats).
- Write down how each is counted, so numbers are comparable quarter to quarter.
- Review them monthly in a short meeting with engineering and security leads, as the Workbook describes for process review.
- Run a four question survey twice a year, adapted from the Google list above.
- When a number looks bad, ask about obstacles before asking about people.
- Publish the scorecard internally, with the same tone as the weekly incident report.
Reading the results
If completion is high but repeats are also high, the actions are probably weak or slow. If reviews are low, people may not trust the process or lack time. The Workbook warns that teams short on time write weaker postmortems and that this makes recurrence more likely, so allocate time to write them and track completion.
How Safeguard fits
Where actions involve dependencies, Safeguard's compliance and evidence automation can keep records of what changed and when. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Is a falling incident count a good sign?
Maybe, but check detection sources and reporting culture first. Fewer reports can mean fewer people speaking up.
How often should we review the scorecard?
Monthly is a common starting point, with a deeper review twice a year.
Sources
- Google SRE book, Postmortem Culture
- Google Site Reliability Workbook, Postmortem Culture
- Atlassian incident management handbook, postmortems
- PagerDuty incident response documentation, postmortem process
Last reviewed: 19 October 2026.
