Skip to main content
Alert sources can fire many alerts for the same underlying issue. Alert grouping groups those related alerts into a single alert group, so you can triage, escalate and attach them to an incident once — instead of handling each alert on its own.

​
How it works

You choose which alerts on a route are grouped together. From widest to narrowest:
  • Alerts arriving within a time window — every alert on the route that arrives within the window joins one group.
  • Alerts with matching attributes — only alerts in the window that share the attributes you pick, such as service or region, join the same group.
  • Alerts that look similar (Beta) — AI groups a team’s alerts in the window that look like the same problem, even when their details differ. See AI-powered grouping below.
Every option groups within a time window, which can work in two ways:
  • Fixed window — the group closes a set time after its first alert arrives.
  • Extending window — the group closes a set time after its most recent alert arrives, so it stays open while related alerts keep arriving.
A group made by time window or matching attributes takes its title and description from the first alert to join.
An alert group for a PodCrashLooping alert, showing five grouped alerts in the left pane and, on the right, the group's related incidents, related escalations, and a timeline recording that the group was created by grouping on Alert Title within an extending 30-minute window

​
Setting up grouping

Grouping is configured per alert route, as the route’s Default grouping config:
  1. Open the alert route you want to group alerts on, and edit its grouping.
  2. Choose which alerts should be grouped together: Alerts arriving within a time window, Alerts with matching attributes, or Alerts that look similar.
  3. For matching attributes, pick at least one attribute to match on.
  4. Choose how long the window is, and whether it’s extending or fixed. Each window type shows how it groups a run of alerts before you pick it.
As you change the settings, a preview shows how your route’s most recent alerts would have been grouped.
The Group alerts configuration on an alert route, with grouping turned on, a 30-minute window set to Extending, and alerts grouped by Alert Title
You can then choose to create an incident from grouped alerts, and whether alerts should also create escalations. When they do, you control how a group pages as new alerts join:
  • On every new alert — page each time an alert joins the group.
  • On priority increase — only page when an alert with a higher priority joins the group.
  • After a grace period — wait a set number of minutes before paging, giving you time to action the alert first.
The escalation options for an alert group, with choices for On every new alert, On priority increase, and After a grace period, and a grace period set to 5 minutes

​
Team grouping preferences

Team grouping preferences let each team choose how its own alerts are grouped, whichever alert route they arrive through. When an alert belongs to exactly one team and that team has a preference, the team’s settings take priority. An alert with no team, or tagged with more than one, always follows the route’s default. Alert routes continue to control escalation, channel messages, and incident creation of both individual alerts and of groups, while team preferences only apply to alert groups.
The Create grouping preference drawer, with the Infrastructure team selected, grouping turned on, a fixed 30-minute window, and all of the team's alerts grouped together

​
Setting a team’s preference

You need teams set up with a Team alert attribute, or a fixed alert source, so that alerts carry a team, and the Manage alert grouping permission. Team grouping preferences are available on the Team, Pro, and Enterprise plans. Removing a team’s preference puts the team’s alerts back on each route’s default.

​
Who can manage preferences

The Manage alert grouping permission is held by Owners and Admins by default, and anyone who holds it account-wide can manage every team’s preference. To let teams manage their own, grant it to a team role. A team’s members can then change their own team’s preference, and nobody else’s.
Preferences belong to teams of your configured team type. Changing that type in Settings → Teams → Configuration removes every team grouping preference.
Team grouping preferences are also available in the public API and the Terraform provider as the incident_team_grouping_preference resource.

​
AI-powered grouping

AI-powered grouping is in beta, and we’re rolling it out gradually.
Some related alerts can look quite different—for example, you might have a Sentry issue fire due to an error in your Orders List API, and a Grafana alert fire due to elevated error rates in the same API. Structurally, these might look entirely different, but AI-powered grouping can identify they’re the same problem and group them together. To turn it on, choose Alerts that look similar in an alert route’s grouping, or in a team’s grouping preference. You’ll need a Team alert attribute and AI processing turned on for your organization. AI only groups alerts from the same team. You can also add attributes that alerts must share before AI will group them—for example, add service if you never want alerts for different services in one group. Even if you let AI group across priorities, you can still choose to be paged when a higher-priority alert joins the group by setting the route to escalate On priority increase. We recommend this setup for most routes. If you use AI-powered grouping, alert groups get their own AI-generated title and description, and you can rename either at any time. We’ll also show you why we grouped the alerts together, which you can see in the timeline on the alert’s page. AI grouping usually groups an alert within a couple of seconds, but if an alert ever waits for more than 30 seconds for AI grouping, we’ll default to handling it on its own and we’ll route it immediately. We also have a rate limit of 120 alerts per minute for AI grouping for a single team. If you go over this limit, we’ll default to handling any additional alerts on their own and routing them as if there was no group.

​
Attaching groups to incidents

If incident creation is enabled on the route, alert groups are attached to incidents automatically. You can also attach a group to a new or existing incident yourself.

​
Managing alerts in a group

Sometimes an alert doesn’t belong in the group it’s landed in. Take one or more alerts out of a group by clicking Ungroup, either for a single alert from its own page, or for several at once from the bulk actions bar. From the dashboard, Slack, or Microsoft Teams, this shows you what the alert route would do with the ungrouped alerts, pre-filled and editable, so you can review and confirm rather than guess:
  • Do you want to create an incident?: create a new incident (pre-filled with the title, severity, type, and any custom fields the alert route would have set, and fully editable), merge into an existing incident, or don’t create one.
  • Do you want to escalate to anyone?: escalate to the people or escalation path the alert route would have paged (also editable), or don’t escalate.
Choosing not to create an incident and not to escalate simply removes the alerts from the group and does nothing else.

​
Private alerts

If you’ve created a private alert route then you’ll be able to group those alerts and create private alert groups. The visibility of private alert groups is inherited from the visibility of the constituent alerts.

​
Alert group limit

We have a limit of 1,000 alerts joining an alert group. Once that limit has been reached, we’ll create a new alert group for subsequent alerts to group into. If this is an issue for your organisation, then please get in touch.

​
FAQs

For groups created by attribute-based grouping, no: their title and description come from the first alert to join and aren’t editable. AI-created groups are different. You can rename their AI-generated title and description at any time.
Either the AI decided it was a different problem, or it couldn’t place the alert in time, or too many alerts arrived at once. In each case the alert is handled on its own and routed as normal. See AI-powered grouping.
No. Groups close automatically when their window expires, or when all attached incidents are resolved. You can resolve a group’s alerts, but there’s no manual close.
They can be — it’s up to you. When you add a Slack or Teams channel to an alert route, that channel has a Send one message per group option, which will send one message per alert group, and update as alerts within the group resolve.
The grouping window is configurable per alert route, up to a maximum of 48 hours — we preselect 30 minutes when you first enable grouping, but you can choose any duration in that range, as either a fixed or extending window. If a new alert arrives after the window has expired, it starts a new alert group (and, if the route creates incidents, a new incident).
Alerts tagged with exactly that team through the Team attribute, on any route. An alert with no team, or with more than one team, follows the route’s Default grouping config. See Alerts and teams for setting the Team attribute.
No. Those settings belong to the route, because they shape the escalation paths and channels that route sends to. A team that needs different escalation behavior needs its own route.
No. A preference is per team and applies on every route its alerts pass through. If a team needs grouping to differ between routes, leave it without a preference and set each route’s Default grouping config instead.
The same as when you change grouping on a route. Alerts already in a group stay there, shortening the window closes any open group that would already have closed under the new window, and lengthening an extending window keeps open groups open for longer. Removing a preference leaves open groups as they are.