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 extracted from the payload or alert fields. To configure:
1

Open the Alert Source

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

Enable Deduplication

Toggle on Combine duplicate alerts into one alert.
3

Choose the Identifier Source

Choose where the identifier comes from:
  • Payload — use a JSONPath into the raw payload (recommended for most cases)
  • Alert field — use a specific alert attribute
4

Set the Deduplication Key Path

Provide the deduplication key path (for example, a JSONPath value). Optionally apply a regular expression to normalize the value before matching.
If deduplication is enabled, Rootly requires a valid unique identifier; the UI will block saves until you configure 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 deduplication key path.

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

​
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 valid unique identifier. If the Combine duplicate alerts toggle is on but the key path is empty or invalid, Rootly blocks the save. Either provide a key path or toggle deduplication off.
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.