Documentation Grafana Cloud Alerts and IRM IRM Configure escalation and routing Alert grouping

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.

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.

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.

For guidance on choosing a stable Grouping Id and recommended grouping strategies per source, refer to Best practices for 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 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

{{ payload.groupKey }}

Keep this default.

To configure grouping in Grafana Alerting, refer to Group alert notifications.

To set up the integration, refer to 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

{{ 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 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.

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.

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 in best practices.

Next steps

• Best practices for alert groups for grouping strategy guidance.
• Configure routing rules to control which alerts reach which group of responders.
• Customize alert templates to edit the Grouping Id template and message formatting.
• Configure escalation chains to define who gets notified when an alert group is created.