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 as a backstop
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 an Alert Source in Rootly Web.
  2. Go to the Events tab.
  3. Toggle on Combine duplicate alerts into one alert.
  4. 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
  5. Provide the deduplication key path (e.g., a JSONPath value).
  6. 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

In addition to key-based dedupe, Rootly can also suppress exact payload duplicates at the team level. This is a backstop for cases where the sending tool retries the same webhook request — for example, when its webhook delivery is configured for at-least-once semantics and Rootly receives the same body twice in quick succession. When enabled, if Rootly sees another alert with the exact same request body as a previous “ignored” event for that alert:
  • The request is counted against the same alert
  • Rootly records an internal event (ignored_alert_request)
  • No new alert is created
Duplicate alerts are not silently discarded.
They are tracked as additional requests on the original alert and reflected in the alert’s counter and timeline events.

​
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.
Either turn off Combine duplicate alerts into one alert on the Alert Source entirely, or change the deduplication key to a field that varies per event (a timestamp, event ID, or unique sequence number). Be aware that disabling deduplication means every repeat event 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.