Here’s something most uptime monitoring companies won’t tell you: the way most tools decide your site is “down” is more fragile than it sounds. We want to walk through why, because understanding it changes how much you should trust a downtime alert, from us or from anyone else.
The naive approach: one server, one opinion
At its simplest, an uptime monitor is one server somewhere in the world, periodically asking your website “are you there?” If it doesn’t get a good answer, it tells you you’re down.
The problem is that a single server checking from a single location can fail to reach your site for reasons that have nothing to do with your site. A routing hiccup between the monitor’s data center and yours. A brief regional network issue. Even something as mundane as the monitor’s own server being briefly overloaded. None of that means your website is down, it means that one path, from that one place, at that one moment didn’t work.
If a monitor acts on that single data point, you get a false alarm: a 3am page for downtime that never actually happened for your real visitors.
The obvious fix, and why it’s expensive
The standard answer is to check from more than one place before declaring something down: run a second (or third) server in a different region, and only confirm downtime if multiple independent locations agree.
That works, but it means paying for extra servers that mostly sit idle, since most checks succeed and never need a second opinion. For a platform trying to stay free forever, “run several always-on servers just in case” isn’t a sustainable answer.
What we do instead
We recently rebuilt how Tethered confirms downtime, and the design goal was: get genuine independence for the confirmation check, without paying for infrastructure that sits idle 99% of the time.
Here’s the flow: when a check fails, we don’t immediately call it downtime. We recheck from the same server a couple of times first, which is cheap, and it catches most transient blips instantly. Only if those retries also fail do we escalate: we call out to an independent check running in a completely different cloud region, on different infrastructure, with a different network path to your site. If that independent check also can’t reach you, we’re confident enough to call it real downtime and send an alert through whichever notification channel you’ve set up. If it can reach you, we’ve just caught a false positive before it ever reached your inbox.
The reason this is affordable is that the independent check only runs for the rare case that actually needs it: a failure that’s already survived a couple of retries. It doesn’t run for every single check on the platform, so we’re not paying for a second server’s worth of always-on capacity to catch a problem that, most of the time, isn’t there.
Why this matters for you
If you’ve ever been burned by a monitoring tool that cried wolf (an alert at an inconvenient hour for downtime that, by the time you checked, was already fine) this is the failure mode that causes it. It’s not that the tool is bad, it’s that “one server’s opinion” was never a reliable enough signal to act on alone.
You shouldn’t have to just trust that your monitor is checking properly. Ask any uptime tool you’re evaluating: what happens between “one check failed” and “you get an alert”? If the honest answer is “nothing, we just tell you immediately,” that’s worth knowing before you’re the one getting woken up over a false alarm.
Curious to see it in practice? Start monitoring for free and put it to the test yourself, on uptime, port, keyword, or SSL checks alike.
Frequently asked questions
What causes a false-positive downtime alert?
Usually a network issue between the monitor’s own server and your site, not an actual outage: a routing hiccup, a brief regional problem, or the monitor’s server being temporarily overloaded. A single check from a single location can’t tell the difference between “you’re down” and “we couldn’t reach you right now.”
How does Tethered avoid false positives?
A failed check is retried a couple of times from the same server first, then escalated to an independent check running in a different cloud region on a different network path. Only if that independent check also fails do we send an alert.
Does this extra check slow down real downtime alerts?
No. The retries and independent check happen within seconds, and only kick in after an initial failure, genuine outages are still confirmed and alerted on quickly.
Is this available on the free plan?
Yes. Every account gets the same independent confirmation check, free or otherwise, since it’s core to how we detect downtime at all.
How can I tell if my current monitoring tool does this too?
Ask the provider directly: what happens between a single failed check and an alert being sent? If there’s no retry or independent cross-check involved, you’re more exposed to false alarms than you might realize.