---
title: "Configure alert grouping | Grafana Cloud documentation"
description: "Configure how Grafana IRM groups related alerts to reduce noise and streamline incident response."
---

# Configure alert grouping

Alert grouping in Grafana IRM combines related alerts into a single alert group so responders see one coherent unit of work instead of a flood of individual notifications. Effective grouping reduces noise, preserves context across related alerts, and keeps escalation behavior predictable.

This page explains how grouping works, the configuration choices to make per integration, and how to edit the Grouping Id template that controls grouping behavior. For strategy guidance and recommended templates per source, refer to [Best practices for alert groups](/docs/grafana-cloud/alerting-and-irm/irm/guides/best-practices/alert-groups).

## How alert grouping works

When an alert payload arrives at an integration, IRM evaluates routes first and then evaluates grouping. The Grouping Id template determines which alerts belong together.

The flow is:

1. A payload arrives at an integration.
2. IRM evaluates routes top to bottom and selects the first match.
3. IRM evaluates the Grouping Id template against the payload to produce a grouping identifier.
4. The payload joins an existing **open** alert group with the same identifier on the same route, or IRM creates a new alert group.

A few principles shape this behavior:

- Alerts on different routes never group together, even when their Grouping Id values match.
- Each integration has its own grouping configuration.
- Each payload is treated as an independent event. IRM doesn’t update past payloads.

For details on the routing step that runs before grouping, refer to [Configure routing rules](/docs/grafana-cloud/alerting-and-irm/irm/escalation-and-routing/routing-rules).

## How alerts are matched to a group

The Grouping Id is the value produced when IRM applies your Grouping Id template to an incoming payload. Two payloads on the same route group together when:

- They produce the same Grouping Id.
- An open alert group with that Grouping Id exists.

If no open alert group with that Grouping Id exists, IRM creates a new one.

Each integration ships with a default Grouping Id template. You can override the default in the integration’s template editor.

For Grouping Id template syntax, available variables, and the editor workflow, refer to [Customize alert templates](/docs/grafana-cloud/alerting-and-irm/irm/escalation-and-routing/customize-alert-templates).

For guidance on choosing a stable Grouping Id and recommended grouping strategies per source, refer to [Best practices for alert groups](/docs/grafana-cloud/alerting-and-irm/irm/guides/best-practices/alert-groups).

## Open and resolved alert groups

An alert group’s state determines whether it accepts new payloads. Open alert groups continue to absorb matching payloads; resolved alert groups don’t.

An alert group is **open** when its state is Firing, Acknowledged, or Silenced. Open alert groups accept new payloads with a matching Grouping Id.

A **resolved** alert group is closed to new payloads. When a new payload arrives with a Grouping Id that matches a resolved group, IRM creates a new alert group instead of reopening the old one.

Two behaviors are worth calling out:

- **Auto-resolution exception**: If an integration has auto-resolution enabled and a resolved-state payload arrives when no open alert group matches, IRM attaches the payload to the most recent matching alert group. This avoids creating a new, already-resolved alert group for every resolve signal.
- **Silence forever**: If you silence an alert group forever and the integration doesn’t have auto-resolution configured, the group stays open and keeps absorbing matching payloads indefinitely. Use time-limited silences when possible, and review any “Silence forever” groups periodically.

For guidance on when to use auto-resolution and time-limited silencing, refer to [Alert group lifecycle](/docs/grafana-cloud/alerting-and-irm/irm/guides/best-practices/alert-groups/#alert-group-lifecycle) in best practices.

## Grouping with Grafana Alerting and Alertmanager

For Grafana Alerting and Prometheus Alertmanager integrations, configure your grouping strategy in the alert source itself, not in IRM.

By default, IRM groups these integrations using `payload.groupKey`, which encodes how the source system grouped the alerts. The default Grouping Id template is:

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

```jinja2
{{ payload.groupKey }}
```

Keep this default.

> Caution
> 
> Don’t change the Grouping Id template for Grafana Alerting or Alertmanager integrations. The status field in the payload refers to the source system’s grouping. Changing the Grouping Id template causes IRM to apply status updates to the wrong alert group, which breaks auto-resolution.

To configure grouping in Grafana Alerting, refer to [Group alert notifications](/docs/grafana/latest/alerting/fundamentals/notifications/group-alert-notifications/).

To set up the integration, refer to [Integrations](/docs/grafana-cloud/alerting-and-irm/irm/integrations).

## Grouping for other integrations

For webhook and non-Alertmanager integrations, choose a Grouping Id template that produces a stable identifier across related payloads.

Common patterns:

- **Reuse the source system’s group concept**: If the source has a native group identifier, such as a Datadog monitor ID or PagerDuty incident key, use it directly.
- **Compose a stable key**: When no native group identifier exists, combine the alert name with a key dimension. For example, alert name plus service, namespace, or instance.

A common composed pattern is:

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

```jinja2
{{ payload.alertname }}:{{ payload.labels.service }}
```

Adjust the fields to match the payload structure of your source system.

For per-source grouping strategies and example templates, refer to [Configure grouping templates](/docs/grafana-cloud/alerting-and-irm/irm/guides/best-practices/alert-groups/#configure-grouping-templates) in best practices.

## Edit the Grouping Id template

Edit the Grouping Id template from the integration’s template editor.

1. Navigate to the **Integrations** page and select your integration.
2. Scroll to the **Templates** section and click **Edit**.
3. Select **Grouping Id** from the list of behavioral templates.
4. Update the template. The right column shows the rendered Grouping Id for the example payload in the left column.
5. To validate against a real payload, select a recent alert group from the **Recent Alert group** dropdown.
6. Click **Save** when the rendered value matches what you expect.

For the full template editor reference, including custom payloads and other template types, refer to [Edit templates](/docs/grafana-cloud/alerting-and-irm/irm/escalation-and-routing/customize-alert-templates/#edit-templates).

## Troubleshooting

Use this section when grouping doesn’t behave as expected.

### A new alert created a separate group instead of joining an existing one

Common causes:

- The two payloads matched different routes. Alerts on different routes never group together.
- The Grouping Id template produced different values for the two payloads.
- The previous alert group was already resolved.
- The two payloads came from different integrations.

To investigate:

1. Open both alert groups and compare the incoming payloads.
2. In the integration’s template editor, render the Grouping Id template against each payload to confirm the values differ.
3. Check the route each payload matched.

For template testing in the editor, refer to [Edit templates](/docs/grafana-cloud/alerting-and-irm/irm/escalation-and-routing/customize-alert-templates/#edit-templates).

### All alerts in a group show identical content

Notification templates render against a single payload in the alert group, not a merged view of every grouped payload. As a result, all alerts in the group can appear identical.

To make grouped alerts more useful:

- Update the message template to include differentiating context, such as instance, value, or labels you expect to differ across the group.
- If grouped alerts represent meaningfully different events, adjust the Grouping Id template to split them into separate groups.

### Auto-resolution stopped working after editing templates

If you changed the Grouping Id template on a Grafana Alerting or Alertmanager integration, auto-resolution can break. The payload’s status field refers to the source system’s grouping, so a custom Grouping Id template causes IRM to apply resolve signals to the wrong alert group.

To fix this, revert the Grouping Id template to the default for these integrations and configure your grouping in the alert source.

### Routing or grouping based on alert status

Don’t route or group on alert status fields such as Firing, Resolved, or OK. Status-based grouping splits firing and resolved payloads for the same issue into different alert groups, which breaks auto-resolution and makes alert groups incoherent.

For more anti-patterns to avoid, refer to [Common pitfalls](/docs/grafana-cloud/alerting-and-irm/irm/guides/best-practices/alert-groups/#common-pitfalls) in best practices.

## Next steps

- [Best practices for alert groups](/docs/grafana-cloud/alerting-and-irm/irm/guides/best-practices/alert-groups) for grouping strategy guidance.
- [Configure routing rules](/docs/grafana-cloud/alerting-and-irm/irm/escalation-and-routing/routing-rules) to control which alerts reach which group of responders.
- [Customize alert templates](/docs/grafana-cloud/alerting-and-irm/irm/escalation-and-routing/customize-alert-templates) to edit the Grouping Id template and message formatting.
- [Configure escalation chains](/docs/grafana-cloud/alerting-and-irm/irm/escalation-and-routing/escalation-chains) to define who gets notified when an alert group is created.