Alert deduplication (dedup) groups multiple alerts that describe the same issue into a single notification or incident. Alerts are matched using a fingerprint such as service name, check ID, or error type.
Why it matters
One failing database can trigger alerts from every service that depends on it. Receiving 200 pages for one root cause overwhelms the on-call person, buries the important signal, and wastes minutes sorting noise during an outage. Deduplication reduces alert fatigue and keeps attention on the cause rather than the symptoms.
Example
09:00:01 api-1 connection refused to db-primary
09:00:01 api-2 connection refused to db-primary
09:00:02 worker connection refused to db-primary
...With a dedup key of db-primary:connection_refused, these become one incident with a counter: "connection refused to db-primary (x143)". New alerts with the same key update the existing incident instead of paging again. When the key's alerts stop and a recovery arrives, the incident resolves.
Dedup is related to, but different from, grouping (bundling related but not identical alerts) and suppression (muting alerts during a maintenance window).
Common mistakes
- Choosing a fingerprint so broad that two different problems merge and one is missed.
- Choosing one so narrow that nothing dedups, such as including a timestamp.
- Leaving deduped incidents silent forever with no re-notification after a long unacknowledged period.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.