70 false alerts a day: why uptime monitors cry wolf — and what the fix costs

July 12, 2026 · 8 min read

There is a sentence in a sysadmin thread that should end the career of any monitoring product: "anyone still on this service needs to verify, don't trust, any outage notifications." Read that again. People are paying for alerts, and then paying with their own time to check whether the alerts are real. At that point the product has inverted its own purpose. Let's look at why this happens — it is architecture, not incompetence — and at what an actual fix looks like.

What people are actually living with

These are real users, in public, about mainstream monitoring tools:

"I'm still getting over 70 false positives per day."r/selfhosted

"I've just deleted my account because they've sent me no less than 140 emails telling me things are up, down, back up again… But everything of mine is up and running."r/sysadmin

"Got paged into work because [the monitor] is claiming some of our sites are flapping… not finding a single issue."r/sysadmin

"We'd have times where the netops ring group would get 10+ false positives in a single night. They tried to blame everything on us, and then tried to blame our ISP (we are the ISP)."r/msp

And an agency describing what a WordPress plugin's built-in monitor did to them: "yesterday alone I received 69 emails, yet the site has never been down. The graph within the control panel shows the site as having 100% uptime." The tool contradicted itself in the same interface, and still sent the emails.

This is not a bug report. This is a genre.

One probe, one opinion

Most monitoring checks your site from a single location. That single probe cannot distinguish between two very different events:

• Your site is down.
• The path between that one probe and your site is having a bad ten seconds.

From the probe's vantage point, they are identical: a request went out, nothing came back. So it fires. Your visitors, coming from other networks, notice nothing at all.

The internet is not a wire; it is a negotiation. Routing flaps, transient packet loss, an overloaded probe host, a DNS resolver having a moment — all of it produces the same silence as a genuinely dead server. If your architecture is "one prober, one verdict", you have signed up for a permanent stream of ghosts.

The workarounds people reach for — and why they're half-fixes

"Whitelist our IPs at your firewall"

This is the most common vendor answer, and users are unimpressed:

"Their solution is to add all 100+ IPs to our firewalls allowed list. This is not feasible when you're managing SonicWALL firewalls."r/sysadmin

Sometimes the probe really is being rate-limited or blocked, and whitelisting genuinely helps. But it fixes one cause of false alerts, not the class. Routing hiccups do not care about your allowlist.

"Just raise the timeout"

Raising the timeout buys you a slower, quieter monitor — and a longer delay before you learn about a real outage. It trades one failure mode for another rather than solving anything.

Turning the monitor off

It sounds absurd until you meet an MSP that has done exactly that:

"each time we end up turning it off… as it creates false positive like crazy. We would get automated calls at night telling us servers are down etc. when there is nothing wrong."r/msp

This is the real end state of a noisy monitor. Not "we tolerate some noise" but "we disabled it". A monitor everyone has muted is worse than no monitor, because it also gives you the illusion of coverage.

The fix that works — and where it usually lives

Two mechanisms kill the overwhelming majority of false alerts, and neither is exotic:

1. Confirmation from multiple locations. Before declaring a site down, ask several probes in different networks and geographies. If one says "unreachable" and three say "loads fine in 200 ms", the site is fine and one probe had a bad moment. Only a quorum opens an incident.
2. Debouncing. Require a few consecutive failures before alerting instead of firing on the first blip. Costs you seconds on a real outage; removes an entire category of noise.

Here is the uncomfortable part. On several popular services, these fixes are premium features. A user, on the free tier, drowning:

"an easy fix would be to change settings so it only considers the service as down after 2 or 3 consecutive failed health checks, but again, this can only be done in the paid tier."r/selfhosted

Think about what that pricing decision means. The free plan is not merely limited — it is engineered to be the noisiest one, and the way out is a subscription. The product is selling you relief from a problem it kept in place.

We put both mechanisms on every plan, including the free one. Not out of generosity: an alert that people have learned to ignore is not a cheaper product, it is a broken one. If our free tier trained you to mute us, our paid tier would never get the chance.

The other side of the coin: the 5-minute blind spot

False alarms are the loud failure. There is a quiet one that costs more.

Most free tiers check every five minutes. An outage that lasts two minutes — a PHP-FPM pool exhausting itself, a database deadlock, a deploy gone wrong and rolled back — can fall entirely between two checks. You get no alert. You get a clean uptime graph. Your client gets an error page.

When a user reported exactly this, a vendor's support said the quiet part out loud: "the downtime may have been intermittent where the 5-min intervals may not have caught." That is the trade being made on your behalf: a monitor that alerts on ghosts and sleeps through the real thing.

Our checks run every minute — on every plan, free included. A one-minute interval does not eliminate the blind spot (nothing short of continuous observation does), but it shrinks it by a factor of five, and it does not require a credit card.

What good looks like

That last row is the whole point. The value of an alert is not in its delivery — it is in whether anyone believes it. Every false positive spends a little of that credit, and the balance does not refill.

One more thing a quorum gives you for free

Once several regions check independently, disagreement between them stops being noise and becomes information. If Amsterdam and Buffalo load the site fine and two other regions time out, the server is healthy and something in the network — a route, a regional block, a CDN rule — is cutting off part of the audience. A single probe cannot tell you that. It can only be right or wrong.

That is the difference between "your site is down" (often untrue) and "your site is unreachable from part of the world" (specific, actionable, and impossible to fake with one prober).

FAQ

Why does my uptime monitor say the site is down when it isn't?

Almost always because a single probe checks from a single location. A routing blip, packet loss, a DNS hiccup or the probe host being briefly overloaded looks exactly like a real outage from that vantage point. Visitors elsewhere never notice, but the monitor pages you anyway.

What actually fixes false downtime alerts?

Confirmation from multiple locations (only alert when a quorum agrees) and debouncing (require several consecutive failures). Whitelisting the monitor's IPs at your firewall fixes one cause, not the class.

Can a 5-minute check interval miss a real outage?

Yes, and vendors admit it. An intermittent two-minute outage can fall entirely between two five-minute checks — no alert, clean graph, angry client.

Is multi-location confirmation a premium feature?

On many services, yes — both confirmation and debouncing sit behind the paid tier, which makes the free plan the noisiest by design. We put both on every plan, including free, because an alert people have learned to ignore is worse than no alert.

Read next: Your uptime monitor keeps crying wolf and What an agency-grade alternative needs.