Incidents repeat when the actions from the first one did not close, were too weak, or lost out to feature work. Ask six questions: are actions slow to close, is feature speed beating reliability fixes, were the right actions captured, is the service overdue for rework, are patches hiding a deeper problem, and was the postmortem read at all?
What the guidance says
Google's Workbook has a short section on repeating incidents. If failures mirror previous ones, it advises digging deeper with questions such as: are action items taking too long to close, is feature velocity trumping reliability fixes, are the right action items being captured in the first place, is the faulty service overdue for a refactor, and are people putting band aids on a more serious problem. If a systemic issue appears, it suggests bringing the collaborators from each similar incident together to decide how to prevent more repeats.
Its own case study shows both sides. After a decommissioning incident, the team spent several weeks adding sanity checks. Three years later, a similar incident happened, and the earlier actions dramatically reduced its blast radius and rate. So actions worked, but the class of problem returned.
The six questions, applied to security
| Question | What to check | Where to look |
|---|---|---|
| Are actions closing? | Age of open actions from past postmortems | Ticket tracker |
| Is delivery beating risk work? | Were fixes deferred more than once? | Sprint history |
| Were the right actions chosen? | Did they prevent or only mitigate? | Postmortem action table |
| Is the system overdue for rework? | Same component in three incidents | Incident tags |
| Are we patching symptoms? | Fix removed one case, not the class | Cause analysis |
| Did people read it? | Who saw the postmortem | Sharing list |
Steps to investigate a repeat
- Pull the earlier postmortems and list every action with its status.
- Mark which ones were never done, partly done or done but ineffective.
- Compare the causes. Look for a shared contributing factor, such as a missing control or an ownership gap.
- Ask the owners of delayed actions what blocked them, in a way that finds obstacles, not culprits.
- Write one combined action list with a single owner and a deadline, and escalate to a manager who can trade off competing work.
- Record the pattern in your incident tags, so future repeats are easier to spot. See how to tag past incidents.
For the follow-up discipline itself, see the postmortem was good, the actions were not done and turn postmortem actions into sprint work.
Don't forget the people factor
Google's guidance cautions that without enough time to write good postmortems, quality drops and incomplete action items make recurrence more likely. It also says postmortems are letters to future team members, and a low bar teaches the wrong lesson. If a repeat arrives and nobody remembers the previous review, treat that as a finding on sharing, not on memory.
How Safeguard fits
In dependency related repeats, such as the same class of vulnerable library appearing again, Safeguard's policies and gates can enforce a rule in the pipeline, and its SBOM scanning shows where the component still lives. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Does a repeat mean the first postmortem failed?
Not always. The first set of actions may have reduced impact while the broader problem remained. Check what was done and what was left.
Who should lead the investigation of a repeat?
Someone with authority across teams, since repeats often involve competing priorities.
Sources
Last reviewed: 19 October 2026.
