"Duplicate" alerts aren't duplicates.

Repetition is information. Deduplication deletes it.

Monitoring does not send copies, it sends repeated observations of a condition that is still true. Calling them duplicates implies waste to be deleted, and deleting them destroys exactly what the repetition carries, how often, how hard, whether it is getting worse, and whether it is spreading. The right operation is not deduplication. It is folding the same condition into one piece of work while keeping every observation.

"Duplicate" is a claim, this item is a copy, it adds nothing, discard it. That is true of a duplicated ticket. It is false of a repeated alert, because monitoring is not a clumsy sender re-posting the same message, it is an instrument reporting that the condition is still true, again, right now. A copy carries no information. A repetition carries plenty, and a feature named deduplication is a promise to throw it away.

Kept, the repeats answer questions a single alert cannot. The count says how hard the condition is firing. The cadence separates a burst from a chronic grumble, every thirty seconds is a different problem than once an hour, from the same monitor. The spread is the most valuable of all, the same condition appearing on a second system is not a duplicate, it is propagation, live, and suppression-by-sameness is precisely the machinery that hides it. And history like "third time this week" only exists if the first two times were kept.

And the most under-read of them is not about timing at all, it is about what the payload said. Four firings of one check arrive at 80, 80, 80, then 99. Every one is the same condition on the same system, so every deduplication scheme on the market calls the fourth a repeat. It is not a repeat. It is the same signal reporting a different reading, and the only reason anyone can tell is that the first three were kept to compare it against.

Deduplicating as Known because the alert fired 5 minutes ago is a trap you learn on day 1 in the NOC. Conditions change, and treating the 4th alert the same as the first will eventually lead to a miss.

There is a second failure hiding in the same word, over-merging. Two alerts that look alike are not necessarily the same condition. "Payment.Error (processor-one)" and "Payment.Error (processor-two)" resemble each other as text and describe two different problems on two different dependencies, merge them and two histories corrupt each other. Sameness has to be decided on the condition and the system it fired on, not on string resemblance. Both failure modes, deleting real information and merging unrelated conditions, come from treating sameness as a text question. It is an identity question.

The operation an ops room actually needs is signal normalization, recognize repeated observations of the same condition, fold them into one piece of work, one card, a count, a timeline, and keep every observation underneath. The operator's experience is what deduplication promised, handle it once. The record's experience is the opposite of deduplication, nothing is lost, so the burst has a shape, the spread is visible, and next week's firing arrives with this week's history attached.

Signal9 groups alerts into events by identity, not resemblance, one condition on one system is one piece of work, however many times it fires, and every firing is kept, because the count, the cadence, and the spread are the parts that make the next decision smarter. Kept firings are also what make a shift visible, Signal9 reads the values inside each payload against that signal's own history and marks the firing that came in different, so the fourth one does not file itself as another repeat. Quiet for the operator, nothing lost for the record.

What is alert deduplication? A common feature that collapses repeated alerts into one and treats the later ones as copies. The framing is wrong for monitoring data. Repeats are fresh observations that a condition is still true, and they carry the count, the cadence, whether the reading is changing, and whether it is spreading. The deeper cost is not lost detail, it is that a firing labelled a duplicate is filed as already known, so the alert proving something moved arrives looking like the three before it. The better operation is normalization, grouping the same condition into one piece of work while keeping every observation.

Should duplicate alerts be suppressed? Grouped, not suppressed. The operator should handle one item per condition, but the repeats underneath should be kept, because they separate a burst from a chronic pattern, show a condition spreading to new systems, and reveal a changing reading. Four firings at 80, 80, 80, then 99 are the same condition reporting something new, and only the kept repeats make the fourth one legible. Suppression buys quiet by deleting the evidence that anything changed.

How does PagerDuty alert deduplication work? PagerDuty deduplicates on a dedup key, a string the alert source supplies in the Events API v2 payload. Events sharing a key collapse into the same alert and incident while that incident is open, each later event appended to the alert log, and if no key is sent PagerDuty generates one per event so nothing groups. Two things follow. What counts as the same condition is decided by whoever wrote the monitoring integration, not by the platform or the operator, and a key that is too general merges unrelated conditions, a documented failure mode in vendor integrations. The repeats are retained as log entries, but nothing measures whether the readings inside them changed.

Is alert deduplication a best practice? The consensus treats it as one, and most alerting platforms ship it as a headline feature, because collapsing repeats genuinely reduces what an operator has to look at. The counterpoint, the position Signal9 takes, is called signal normalization. Repeats are observations, not copies, so the right operation groups the same condition into one piece of work while keeping every observation, because the count, the cadence, a changing reading, and spread to a second system only exist in the kept repeats. The practical test is simple. If the fourth firing reads 99 after three at 80, does your tooling notice, or does it file a repeat?

How does Signal9 handle duplicate alerts? It treats them as repeated observations of one signal. The same condition on the same system folds into one event with its count and timeline, nothing is deleted, and the same condition on a different system is kept separate and shown as spread, never merged on resemblance. Signal9 also reads the values inside each payload against that signal's own history and marks the firing that came in different, so a fourth alert reading 99 after three at 80 is surfaced rather than filed as another repeat.