Gallo's work← All posts

Monitoring

The Hidden Cost of False Alerts (And Why They're Worse Than No Alerts)

A monitoring tool that cries wolf once a day is worse than no monitoring at all.

Gallo's work · 5 min read

The failure mode nobody talks about with monitoring isn't missing an incident. It's building something so noisy that a real incident looks exactly like every other alert you've already learned to ignore.

This happens gradually, which is what makes it dangerous. Nobody decides to stop caring about alerts. They just get trained out of it, one false positive at a time.

How the training actually happens

Day 1Alert fires. You check it immediately. It's a real issue.
Day 4Alert fires again. Same workflow. Turns out it was a record that just arrived a little late. Not actually broken.
Day 9Same thing. You start checking it a bit later, after your coffee.
Day 15You mute the channel for that workflow. You'll “check it when you have time.”
Day 23The alert fires for real this time. You don't see it until the client emails.

Nothing about this timeline required carelessness. Every individual decision was reasonable given what came before it. That's what makes alert fatigue different from most failures, it's not a mistake, it's a rational response to a system that trained you to stop trusting it.

What actually causes false positives

The most common cause is one that sounds harmless: checking too soon. A record that's genuinely on its way, just running a few minutes behind, gets flagged as missing before it's had a fair chance to arrive.

checked at 14:00 → record missing → alert fires
record actually arrives at 14:02, two minutes late

The record wasn't lost. It was never given the time it needed. And because the alert fired anyway, the system just taught you that its alerts don't always mean something's actually wrong.

The two things that actually fix it

First, only evaluate what's had time to arrive. Measure the real, observed delay between something happening and it showing up downstream, then only flag records older than that window. A record that's still within its normal arrival time was never eligible to be a false positive in the first place.

Second, never alert on the first miss. A record that's missing gets held quietly and rechecked on the next cycle. If it's shown up by then, it's dropped silently, no alert, no noise. Only a record that's still missing after two consecutive checks is treated as a real problem.

14:00 → 7 records missing → held, not alerted
14:15 recheck → 4 landed since, 3 still missing → now confirmed, alert fires

That combination, a fair waiting window plus requiring the problem to persist across two checks, is what kills almost all transient noise without meaningfully slowing down real detection. The alerts that do fire have earned it.

The test that matters

Think about the last false alarm your current setup generated, if you have one. Did it change how quickly you reacted to the next one? If the honest answer is yes, that's the actual cost. It's not the noise itself, it's what the noise trains you to stop noticing.

Related reading

Automation Agency Client Retention Starts Before Something Breaks
Why retention is decided months before the incident call, not during it.
The Real Cost of a Client Finding a Broken Automation Before You Do
Why the bug is the cheap part, and what actually costs an agency trust.
5 Signs Your Automation Agency Needs Better Client Monitoring
Five honest signs your current setup is closer to a liability than a safety net.

Alerts you can actually trust.

Start monitoring