You get paged. You open your laptop, half-panicked, and by the time the page loads the site's already back. No cause, no pattern, just a blip that resolved itself in the time it took you to sit up. It happens again the next week. By the third time, you've muted the channel.
The danger of a false alert isn't the false alert itself — it's what it trains you to do. Every alert that turns out to be nothing makes the next one, including the real one, a little easier to dismiss. A monitor that sends enough false alerts gets muted right before the outage that actually mattered.
Where false alerts actually come from
Almost none of them are your site actually being down. They're something transient, upstream, or borderline — reported as an outage by a monitor that only knows how to say "up" or "down," with no room for "technically failed this one check."
- A single dropped packet. One check, one moment, one network hiccup between the monitor and your server that has nothing to do with your site's actual health.
- A response that landed right on the timeout line. Your server answered — just a few hundred milliseconds slower than usual, enough to trip a check that treats "slow" and "down" as the same thing.
- A brief blip on the monitoring side, not yours. The checking service itself has a rough moment. Rare, but it happens, and a monitor with no cross-check has no way to tell the difference.
- Real, repeated flapping. The site genuinely bounces up and down every few minutes — which is a real problem, but one that deserves a single "this is unstable" alert, not a fresh page every single time it flips.
The fix isn't fewer checks — it's smarter alerting
The instinct is to check less often, on the theory that fewer checks means fewer chances to catch a fluke. That just means a real outage takes longer to notice. The actual fix is separating "one check failed" from "this is an outage," which is a different problem entirely:
- Confirm before you declare it down. One failed check is a data point, not a verdict. A second check, moments later, is what turns "might be nothing" into "worth waking someone up for."
- Give it a moment before the first page. Most transient blips resolve themselves inside a minute. An alert delay of even a couple of minutes filters out the vast majority of nothing-burgers without meaningfully delaying real detection.
- Suppress the flap, don't repeat it. If a site is bouncing up and down every few minutes, that's one incident, not a dozen. Getting paged once for "this is flapping" is useful. Getting paged every single flip is exactly what gets a channel muted.
If you can't remember the last time an alert turned out to be nothing, your monitor isn't quiet because everything's fine — it's quiet because you stopped trusting it enough to notice.
A simple way to think about the threshold
There's no universal right answer — a payment endpoint and a personal blog shouldn't use the same settings. The question worth asking for each monitor is: how bad is it if I get paged for nothing, versus how bad is it if I miss something real? A checkout flow should probably err toward paging fast, even at the cost of an occasional false alarm. A low-traffic status page can afford to wait for a second confirmation before bothering anyone.
That's the reasoning behind Impulseye's per-monitor Alert Sensitivity settings — confirmation checks, a minimum downtime before the first alert, and flap suppression, all adjustable per monitor instead of one global setting that's wrong for half of what you're watching. The goal isn't fewer alerts. It's making sure the ones you get are the ones worth trusting.
Start with the defaults — they're tuned for the common case — and only touch the sliders once you've actually seen your monitor send a false alert.