Skip to main content

​
Overview

Monitoring systems often keep sending events while a condition remains unhealthy — the same Datadog monitor or CloudWatch alarm can fire every minute until you mitigate. Without intervention, that’s one new Rootly alert per event and one page per alert. Alert Deduplication collapses those repeat events onto a single open alert, so the responder sees the count climbing instead of getting paged again. Rootly provides two layers of deduplication:
  1. Configurable per–Alert Source dedupe — by stable unique identifier (the primary mechanism)
  2. Payload-based duplicate suppression — exact-body matching, active whenever deduplication is enabled for your account
Together they keep the alert list clean while preserving a full history of how often a condition has fired.
Trying to decide between Alert Deduplication and Alert Grouping? Use the picker on the Alerts page — same monitor re-firing → Deduplication; multiple different monitors lighting up at once → Grouping; both → enable both.

​
Combining Alerts by Unique Identifier

At the Alert Source level, you can tell Rootly to combine duplicate alerts into one alert using a stable identifier read from the alert payload. To configure:
1

Open the Alert Source

Open an Alert Source in Rootly Web and go to the Events tab.
2

Set the Unique Identifier

In Unique Identifier, enter a JSONPath that points at the identifier in the raw payload, such as $.alert_id. Paths start at the root of the payload, so don’t prefix them with $.payload. Optionally add a regular expression in the second field to extract or normalize part of the value before matching. On Generic Webhook and Email sources, auto-resolution matches recovery events using this same identifier.
3

Enable Deduplication

Toggle on Combine duplicate alerts into one alert.
If deduplication is enabled, Rootly requires a unique identifier, and the UI blocks the save until you enter one.
In the Alert Source UI, you can preview sample alerts.
Clicking a purple pill in the payload viewer copies its JSONPath — use this directly as your unique identifier. The preview under the field recognizes simple paths only, such as $.monitor.id. An expression that lists several keys shows No data found for the given JSONPath in the preview, but Rootly still evaluates it on incoming alerts.

​
What Happens When a Duplicate Arrives

When a new alert arrives and its deduplication key matches an existing open alert, Rootly:
  • Does not create a new alert
  • Adds a duplicate/ignored request event to the original alert
  • Increments the alert’s requests count
  • Updates last_request_at
This behavior shows up in the UI as:
  • A badge like ×3 next to the alert
  • A tooltip indicating how many matching requests have been received and when the last one arrived

​
Choosing a Stable Deduplication Key

The whole mechanism depends on the key being stable across repeat events. Aim for fields the sending tool guarantees are constant for the same underlying condition:
  • Monitor IDs (Datadog alert_id, CloudWatch alarm ARN, PagerDuty incident key)
  • Ticket or issue IDs (Jira issue key, Zendesk ticket ID, Sentry issue ID)
  • External identifier fields mapped through your alert source configuration
Avoid:
  • Free-form message text (likely to vary between events)
  • Timestamps (always vary)
  • Aggregated counts or percentages embedded in the payload
If you’re not sure what’s stable, start with a narrow key (a specific JSONPath) and watch the requests count. If repeat events are properly stacking, the count climbs on the original alert instead of new alerts appearing.

​
When the Identifier Moves Between Event Types

Some tools nest the identifier under a different top-level key depending on the event type. For example, a metric alert and a log alert from the same tool might look like this:
You don’t need a separate Alert Source for each shape. List the possible keys in one JSONPath expression, with each key in single quotes:
Rootly uses the id from whichever of those keys the payload contains. The quotes are required. Without them, the expression doesn’t evaluate and Rootly can’t read an identifier. Avoid wildcards such as $.*.id or $..id. They match every id in the payload, and Rootly uses the first one found, which can belong to an unrelated object elsewhere in the payload. Unrelated events then combine into one alert.

​
Payload-Based Duplicate Suppression

Alongside key-based dedupe, Rootly matches on the exact request body. This check runs whenever deduplication is enabled for your account, whatever the Combine duplicate alerts into one alert toggle is set to. The match is scoped per team and per Alert Source, and compares the request body byte for byte. When a request body matches an alert that is still open, Rootly:
  • Creates no new alert and sends no page
  • Returns HTTP 200, naming the alert the request matched:
  • Leaves the existing alert untouched — the requests count stays where it is, and the timeline records nothing
That response is the only record of a suppressed request.

​
How Long a Body Match Lasts

A body match holds for 31 days from the first request. If rolling-window suppression is enabled for your account, each matching repeat restarts the 31 days.
Resolving the alert clears the match. Acknowledging it does not.
An alert left acknowledged keeps suppressing identical payloads for the rest of the window, so a condition that re-fires with the same payload stays silent until you resolve the original alert.

​
Making Every Repeat Create an Alert

To have each repeat create its own alert — when testing an integration, for example — include a value that changes per event in the payload, such as a timestamp, event ID, or sequence number. A body that differs by a single character starts a new alert.

​
Best Practices

  • Choose a stable deduplication key. Use identifiers like monitor IDs, incident keys, or ticket IDs — avoid full message text or highly variable fields.
  • Start narrow, then broaden if needed. Begin with conservative dedup rules and relax them as you gain confidence, to avoid accidentally merging unrelated alerts.
  • Watch the requests count. A high ×N count on an alert is a strong signal of ongoing or flapping conditions and can inform severity and prioritization.
  • Confirm the key normalizes correctly. If your sending tool occasionally varies the key (different casing, extra whitespace), use the optional regex to normalize before matching.
  • Pair with Alert Grouping when you have both noise patterns. If different monitors on the same service all fire at once and each one keeps re-firing, enable both Deduplication and Alert Grouping. Deduplication runs at the source level before alert creation; Grouping runs on whatever survives.

​
Troubleshooting

Confirm that Combine duplicate alerts into one alert is enabled on the Alert Source and that the deduplication key path points to a stable, consistent value across repeat events. Inspect a sample payload in the source preview and copy the JSONPath directly from the purple pill to avoid typos. If the sending tool varies the key between events (different casing, extra whitespace), add a regex to normalize before matching.
Deduplication requires a unique identifier. If the Combine duplicate alerts toggle is on and Unique Identifier is empty, Rootly blocks the save. Either enter a JSONPath or toggle deduplication off.
The preview under Unique Identifier only recognizes simple paths, such as $.monitor.id. Expressions that list several keys, such as $['metric','log'].id, show No data found for the given JSONPath in the preview even when they’re correct. Save the source and send a test event, then confirm repeat events stack on the original alert.
Vary the payload between events — a timestamp, event ID, or unique sequence number — so neither the deduplication key nor the request body matches the open alert. If you are using a deduplication key, point it at a field that changes per event. The Combine duplicate alerts into one alert toggle governs the identifier match only, so exact-body suppression still applies with it off. Resolving the open alert clears any existing match straight away. Every repeat then creates a new alert and may re-page.
Open both alerts and compare the field your deduplication key path points at. Common culprits: the sending tool sends a slightly different value (different casing, trailing whitespace, embedded timestamps), or the key path is too narrow and resolves to slightly different JSON locations in the two payloads. Use a regex to normalize, or pick a coarser stable identifier.

Alert Grouping

The complementary tool — collapse different-monitor alerts on the same underlying incident into a single leader-driven group.

Alert Routing

Route alerts to services, teams, and escalation policies based on payload fields and labels.

Alerts Overview

The umbrella page covering alert ingestion, sources, manual paging, and the noise-reduction picker.