Grouping combines similar alerts into one notification. Inhibition suppresses notifications for some alerts while another, related alert is firing. A silence mutes matching alerts for a set time. Together they cut noise during an outage without turning off the detection itself.
Definitions
The Prometheus Alertmanager overview defines the three ideas this way.
Grouping categorizes alerts of similar nature into a single notification. When a hundred instances fail at once, you want one message listing them, not a hundred pages. Grouping, timing and receivers are set in the routing tree of the configuration file.
Inhibition suppresses notifications for certain alerts if certain other alerts are already firing. The documentation's example: if a cluster is unreachable, mute the alerts about everything running on that cluster. The cause is already known, and the symptoms add nothing.
Silences are a straightforward way to mute alerts for a given time. A silence is defined by matchers, like the routing tree. An incoming alert that matches all of an active silence's matchers produces no notification. Silences are configured in the web interface.
When to use which
| Situation | Use | Why |
|---|---|---|
| Many alerts, same cause, same service | Grouping | One notification, full list inside |
| A parent failure makes children fire | Inhibition | Children are expected and add no new action |
| Planned maintenance or a known bug being fixed | Silence | Temporary, needs an end |
| An alert that is wrong or never acted on | None of these | Fix or delete the rule |
The last row is the important one. These tools hide noise; they do not repair a bad rule. See retire, tune or automate a noisy alert.
Steps to set it up
- Choose grouping labels that match how your team splits work, such as service and environment. Avoid grouping by an ID that is unique per alert, because that defeats the purpose.
- Write down your dependency chains: network before host before service before feature. These become inhibition rules.
- Make sure the alert that inhibits others is reliable. If the inhibiting alert is itself flaky, you can hide real problems.
- Require every silence to carry a comment, an owner and an end time. See why silences should expire.
- Test with a game day: break one dependency in staging and count the notifications.
A security reading
The same ideas apply to security alerts. A new advisory for a library used in forty services should produce one grouped notification naming the services, not forty. A scanner outage should inhibit its own downstream "no findings" alerts, since silence from a broken scanner is not good news.
The documentation does not state how long a silence lasts or how it expires, so check the version you run before you rely on any default.
Quick check
Is inhibition the same as a silence?
No. A silence is a manual mute with matchers and a time window. Inhibition is automatic and depends on another alert firing.
Does grouping lose information?
Not if the grouped notification lists each alert. You get one message instead of many, with the same detail.
Safeguard's policies and gates can route dependency findings by ownership, which pairs naturally with grouped notifications. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
