A good postmortem has actions of three types: prevent the incident from recurring, detect it faster if it does, and mitigate the damage. Each needs one owner, a priority and a ticket. A list made only of mitigations, or only of "improve monitoring", leaves the real cause in place.
The three types
Google's Workbook example action table tags each action as prevent, detect or mitigate, alongside priority, owner and tracking bug. In its deliberately bad example, most actions are mitigative, the single preventive one is "train humans not to run unsafe commands", and priorities are identical across the list.
| Type | Question it answers | Security example |
|---|---|---|
| Prevent | How do we stop this class of event? | Block unreviewed changes to the release workflow |
| Detect | How do we find it sooner? | Alert when a release is published outside the pipeline |
| Mitigate | How do we shrink the impact? | Short lived credentials, so a leak expires fast |
A healthy list usually has at least one of each. If you only have mitigations, ask what would have stopped it. If you only have prevention, ask what happens when prevention fails.
What makes an action good
The Workbook calls out specific weaknesses: ambiguous phrases like "improve" or "make better" that are hard to measure, equal priorities that leave no order of work, and missing owners and tracking bugs. From that we can build a checklist:
- Verb and object. "Add a required reviewer rule to the release branch", not "improve review".
- One owner. A person, not a team. Collaborators can be listed separately.
- Priority. Which one is first, and why.
- A ticket. Without a formal tracking process, the Workbook notes, actions are often forgotten.
- A finish line. How will you know it is done, for example a test or a policy that fails closed.
- A date or target window. Atlassian describes agreed service level objectives of 4 or 8 weeks for its priority actions, depending on the service.
Keep the list short
PagerDuty advises against creating too many tickets and says to generally create only the ones that absolutely should be dealt with, and to weigh trade-offs, since sometimes the return is not worth the effort. Five real actions beat fifteen aspirations. Park the rest in a "considered, not doing" section with a reason, so the decision is on record.
Steps in the meeting
- Ask for prevention ideas first, then detection, then mitigation.
- Rewrite vague items with a verb and an object.
- Assign an owner in the room.
- Agree priority order.
- File tickets before leaving, or within a day.
For turning these into scheduled work, see turn postmortem actions into sprint work.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a gate turns a preventive action into a check that runs on every change.
How Safeguard fits
Preventive actions that can be expressed as rules are good candidates for gates. Safeguard's policies, gates and guardrails apply dependency and build rules in the pipeline, and a free scan is available at https://gold.safeguard.sh/scan.
Quick check
Is "improve monitoring" a valid action item?
Not as written. Say which signal, which threshold, who gets paged and by when.
Should every action be a code change?
No, but prefer system and process changes over training alone. The Workbook says changing human behaviour is generally less reliable.
Sources
- Google Site Reliability Workbook, Postmortem Culture
- Atlassian incident management handbook, postmortems
- PagerDuty incident response documentation, postmortem process
Last reviewed: 19 October 2026.
