"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, 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.

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 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. Quiet for the operator, nothing lost for the record.

What is alert deduplication? A common feature that discards repeated alerts as copies. The framing is wrong for monitoring data, repeats are fresh observations that the condition is still true, and they carry the count, the cadence, and the spread. 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 distinguish a burst from a chronic pattern, show a condition spreading to new systems, and build the baseline that makes an unusual firing recognizable later. Suppression buys quiet by deleting evidence.

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 piece of work 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. The repetition stays available as history, baselines, and patterns.