Retire an alert if nobody has acted on it in a quarter, tune it if it catches a real problem with too much chaff, and automate it if the response is the same every time. Keep paging a human only for the cases that need judgment. That order of questions clears most pager noise.
Step one: gather a quarter of data
For each alert that fired, record whether anyone did anything because of it. Google's SRE book suggests reviewing page frequency regularly, for instance in quarterly reports. A spreadsheet is enough.
Step two: choose a path
Retire when:
- No page led to action in the review period.
- The condition it watches is covered by a better alert.
- The underlying risk no longer exists.
Tune when:
- Real problems are caught, but many false positives come with them.
- A threshold, a time window or an exclusion list could separate the cases.
- The signal measures a symptom, not a cause. The SRE guidance favours paging on symptoms.
Automate when:
- The response is a script someone runs the same way each time.
- The book says pages with rote, scriptable responses are a red flag that technical debt needs fixing or automating.
Keep as a page when:
- It needs judgment, and the cost of delay is real.
A worked example
An alert fires whenever a dependency scanner reports a new high severity advisory. Suppose the review shows that nearly every firing led to no action. The path is tune: add whether the vulnerable code is actually reachable and whether a fix exists, then page only on the combination. Reachability filtering of this kind is one capability Safeguard offers, but the same logic applies with any tool you can configure.
Guard against over-tuning
Tuning can drift into blindness. Keep a record of what you changed and why, and spot-check suppressed events every so often.
Make it routine
A small monthly session works better than a big annual cleanup. Pick the five noisiest alerts. Decide, assign an owner, move on.
Who should decide
Give each alert an owner. Without one, nobody has the authority to retire it. The owner can be a team or a named person, and their name should appear in the alert text.
When two teams disagree, use the evidence from the quarter of data. If an alert has never led to action, the burden of proof is on the person who wants to keep it. If it has caught something real, the burden is on the person who wants to remove it. This simple rule ends most arguments quickly and keeps the discussion about facts.
Quick check
Is deleting an alert risky?
It can be. Keep the detection logging to a queue or dashboard for a while before deleting entirely, so you can see if you miss it.
Sources
Last reviewed: 19 October 2026.
