Alerting

Why One Outage Generated 400 Alerts (And How Deduplication Fixes It)

MontyJun 10, 2025 5 min read 1

A database becomes unreachable at 02:14. By 02:20 the on-call engineer's phone has one hundred and forty notifications. The monitoring worked perfectly. That is the problem.

Where the volume comes from

Two multipliers that compound. Fan-out: eleven services depend on the database, each has its own health check, each fails — one cause, eleven alerts. Repetition: each check runs every minute, so over an hour that is hundreds of alerts. Neither is a bug. The failure is that nothing groups them into the single fact they represent.

What deduplication does

Before creating a new incident, it asks whether this is really new. If an incident for the same thing is already open, the new signal updates it instead of creating another.

Strategy one: deduplicate by source

Each monitor is a source. If a source already has an open incident, further failures do not create new ones. This kills the repetition multiplier entirely. It does not kill fan-out. The check usually includes acknowledged and investigating states too, which means an incident acknowledged by someone not actually working on it creates a silent period.

Strategy two: deduplicate by explicit key

The source sends a stable identifier. Alerts sharing a key collapse into one incident. More powerful because you control the grouping, but it requires cooperation from every source. Where it shines is in your own scripts, where you control the payload.

Strategy three: semantic grouping

Some systems detect that two differently-worded alerts describe the same problem using text similarity. When it works it is impressive, but it is probabilistic — a threshold too loose merges distinct problems, which is worse than duplication because it hides an incident.

When your source has no stable key

Put the state in the sender: have your script track whether it has already alerted and only fire on transitions. Or reduce the evaluation frequency.

Fan-out needs a different fix

Alert on the dependency directly: one monitor on the database itself, and remove the database dependency from the other eleven health checks. This is the highest-leverage change and it is usually resisted because eleven checks feel more thorough. They are not; they are eleven copies of the same information.

Fail open, not closed

When deduplication logic cannot determine whether something is a duplicate, it should create the incident. A duplicate incident is annoying. A dropped incident is an outage nobody was told about.

Monty