---
title: "Configure inhibition rules | Grafana documentation"
description: "Use inhibition rules to suppress notifications for target alerts when a related source alert is already firing. Inhibition rules let you reduce noise by suppressing redundant alerts caused by a known root cause."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# Configure inhibition rules

> Note
> 
> Available in Grafana 13 or higher.
> 
> Inhibition rules require the `alertingMultiplePolicies` feature toggle, which is experimental. Without it, you can create, read, update, and delete rules through the API, but Alertmanager doesn’t apply them during alert evaluation, so it doesn’t inhibit any alerts.
> 
> On Grafana Cloud, contact your account team or support to enable this feature toggle. On self-hosted Grafana, enable the toggle in the `[feature_toggles]` section of your Grafana configuration.

An inhibition rule suppresses notifications for target alerts when source alerts with matching label values are already firing. This lets you reduce noise when a root-cause alert makes dependent alerts redundant.

For example, if a node is down (the **source**), you can inhibit all alerts for services running on that node (the **target**). This prevents your team from receiving individual alerts for each affected service when the underlying cause is already captured in the source alert.

> Note
> 
> Inhibition rules are assigned to a [specific Alertmanager](/docs/grafana-cloud/alerting-and-irm/alerting/configure-notifications/#alertmanager-architecture) and only suppress notifications for alerts managed by that Alertmanager.

> Caution
> 
> Inhibition rules are intended for compatibility with configurations imported from Prometheus Alertmanager or Mimir. They have no dedicated management UI in Grafana by design.
> 
> If not carefully configured, inhibition rules can silently suppress alerts and make issues harder to detect. Consider [silences](/docs/grafana-cloud/alerting-and-irm/alerting/configure-notifications/create-silence/) or [mute timings](/docs/grafana-cloud/alerting-and-irm/alerting/configure-notifications/mute-timings/) for most suppression use cases.

## Inhibition rules vs silences

Both inhibition rules and [silences](/docs/grafana-cloud/alerting-and-irm/alerting/configure-notifications/create-silence/) suppress alert notifications. The key difference is that inhibition rules suppress alerts automatically based on the presence of another alert, while silences suppress alerts for a fixed time window regardless of other alerts.

Expand table

|              | Inhibition rule                               | Silence                                |
|--------------|-----------------------------------------------|----------------------------------------|
| **Trigger**  | Active when a matching source alert is firing | Active during a configured time window |
| **Duration** | Lasts as long as the source alert fires       | Has a fixed start and end time         |
| **Setup**    | Defined as a persistent configuration         | Created manually per occurrence        |

## Manage inhibition rules

You can manage inhibition rules by using the Grafana App Platform API. There is no dedicated UI for creating or editing inhibition rules.

The API resource is:

- **Group:** `notifications.alerting.grafana.app`
- **Version:** `v1beta1`
- **Resource:** `inhibitionrules`

> Caution
> 
> The inhibition rules API is in beta (`v1beta1`) and is subject to change.

Inhibition rules are also supported in the Prometheus Alertmanager. Refer to [Configure Alertmanager](/docs/grafana-cloud/alerting-and-irm/alerting/set-up/configure-alertmanager/) to set up an external Alertmanager.

## Inhibition rule schema

Each inhibition rule has the following fields:

Expand table

| Field             | Required | Description                                                                                            |
|-------------------|----------|--------------------------------------------------------------------------------------------------------|
| `name`            | Yes      | Unique name for the inhibition rule. Immutable after creation.                                         |
| `source_matchers` | Yes      | One or more matchers that identify source (inhibiting) alerts.                                         |
| `target_matchers` | Yes      | One or more matchers that identify target (inhibited) alerts.                                          |
| `equal`           | No       | Labels that must have equal values in both source and target alerts for the inhibition to take effect. |

### Matcher format

Both `source_matchers` and `target_matchers` are lists of structured matcher objects. Each matcher has:

Expand table

| Field   | Description                                                                  |
|---------|------------------------------------------------------------------------------|
| `label` | The name of the label to match against.                                      |
| `type`  | The matching operator. One of `=`, `!=`, `=~`, `!~`.                         |
| `value` | The value to match against. For `=~` and `!~`, this is a regular expression. |

Expand table

| Operator | Description                                                          |
|----------|----------------------------------------------------------------------|
| `=`      | Select alerts where the label equals the value.                      |
| `!=`     | Select alerts where the label does not equal the value.              |
| `=~`     | Select alerts where the label matches the regular expression.        |
| `!~`     | Select alerts where the label does not match the regular expression. |

### The `equal` field

When `equal` is specified, the inhibition only applies when the source and target alerts have the same value for each listed label. For example, setting `equal: [cluster]` ensures that an alert in one cluster only inhibits alerts in the same cluster.

If `equal` is omitted, any firing source alert matching `source_matchers` inhibits all matching target alerts regardless of their label values.

Missing labels and empty-value labels are treated as equivalent for the purpose of `equal` matching.

## Example: suppress warning alerts

The following example defines an inhibition rule that suppresses all `warning`-severity alerts in a cluster when a `critical`-severity alert is already firing for the same cluster.

JSON ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```json
{
  "name": "critical-inhibits-warnings",
  "source_matchers": [{ "label": "severity", "type": "=", "value": "critical" }],
  "target_matchers": [{ "label": "severity", "type": "=", "value": "warning" }],
  "equal": ["cluster", "namespace"]
}
```

In this example:

- The *source* matcher selects `critical` alerts. When one fires, the rule becomes active.
- The *target* matcher selects `warning` alerts. The rule suppresses these while the source alert fires.
- The `equal` field ensures suppression only applies when source and target share the same `cluster` and `namespace` label values.

## Inhibition rules and managed routes

When the `alertingMultiplePolicies` feature toggle is enabled, an Alertmanager can serve multiple routing trees: the default Grafana-managed route and any routes imported from Prometheus Alertmanager or Mimir configurations. Inhibition rules behave differently depending on how each rule is created:

- **Grafana-managed rules** are created through the API and apply across the entire Alertmanager. They can match alerts handled by any route, including imported routes.
- **Imported rules** come from an imported Alertmanager configuration and are scoped to the alerts handled by their imported route. Grafana adds an internal label matcher that limits each imported rule to its own imported route, so an imported rule can’t suppress alerts that flow through other routes.

To suppress alerts across multiple imported configurations, create a Grafana-managed rule through the API instead of relying on the inhibition rules embedded in an imported configuration.