> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Alert Deduplication
> Collapse repeat alerts from the same monitor into one Rootly alert using a stable per-source identifier, so responders aren't re-paged while an issue is still open.
## 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](/alerts/alert-grouping)? Use the picker on the [Alerts](/alerts/alerts#reducing-alert-noise) 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](/alerts/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.
***
## Related Pages
The complementary tool — collapse different-monitor alerts on the same underlying incident into a single leader-driven group.
Route alerts to services, teams, and escalation policies based on payload fields and labels.
The umbrella page covering alert ingestion, sources, manual paging, and the noise-reduction picker.