Because a mute without an end becomes a permanent blind spot. Every silence should record who set it, why, and when it expires, so the alert returns on its own. Review the active list weekly and treat a repeated silence as a sign the rule needs fixing.
What a silence is
Alertmanager describes silences as a straightforward way to mute alerts for a given time. Matching alerts still fire inside the system, but no notification goes out. That is useful during maintenance and dangerous when forgotten.
The same pattern exists elsewhere under other names: snoozing a ticket, ignoring a finding, dismissing a dependency alert. In each case, the mute is a decision, and decisions need an owner and a review date.
How silences go wrong
- Someone silences a noisy alert on a Friday and moves teams. Nobody knows it is muted.
- A broad matcher, such as an entire environment, hides a real incident that begins during the window.
- A long silence set for a one hour job stays active for weeks.
- The same alert gets silenced every month, and the underlying defect is never fixed.
Each of these looks reasonable at the time. The harm shows up later, during an incident, when a notification you would have wanted never arrived.
A silence policy you can copy
| Field | Rule |
|---|---|
| Owner | A named person or team, not "ops" |
| Reason | One sentence plus a ticket link |
| End time | Required, default 4 hours, long ones need a second approver |
| Scope | Narrowest matcher that works, never a whole environment |
| Review | Anything over 7 days is reviewed in the weekly meeting |
Steps
- List current silences today. Note any without a comment or with an end more than a week away.
- Add the policy above to your runbook, and tell the team.
- Add a weekly review item: open silences, longest running, most repeated.
- For any alert silenced three times in a quarter, open a task to tune or retire it.
- Create an alert on the count of active silences, or on a silence older than a threshold, so the list cannot grow unseen.
Security findings follow the same rule
Dismissing a dependency alert is a silence too. GitHub's documentation says an unfixed dismissed Dependabot alert can be reopened, and that a dismissal comment is added to the alert timeline and can serve as justification for auditing and reporting. Use that. Write the reason, and set a calendar date to revisit it, because a vulnerable package that is "not used" today may be used next quarter. See dismiss reasons and reopening Dependabot alerts.
Measuring it
Track three numbers: active silences, median age, and the share with an owner and reason. If the third is below 100 percent, the policy is not working yet. The aim is not zero silences. The aim is that every mute is deliberate and temporary.
Quick check
How long should a silence last?
As short as the work needs. Four hours is a reasonable default for maintenance. Anything over a week should be reviewed by a second person.
Is silencing the same as fixing a noisy alert?
No. A silence defers the problem. If the same alert is muted repeatedly, tune or retire the rule.
Safeguard's policies and gates keep a record of overrides on dependency findings, which supports the same review habit. You can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
