What the check actually does
A basic uptime check sends an HTTP request to a URL you choose — usually the homepage, sometimes a login page or a health endpoint — and records whether it got a response, what status code came back, and how long it took. A healthy result is typically a 2xx status code within an acceptable time window, say a few seconds.
That single check already catches the most common failures: the server not responding at all, a timeout, or an error page (5xx) coming back instead of the site. It won't catch everything — a page that returns 200 with broken content inside it needs a check that also inspects the response body, not just the status code.
Choosing a check interval
The interval is a trade-off between how fast you find out about a problem and how much checking you actually need. A 5-minute interval means the worst case is a 5-minute gap between a real outage starting and a check catching it — fine for most sites, including anything on Holter's free plan, which checks every 5 minutes with no credit card required.
Faster intervals matter more as the cost of downtime rises — a checkout flow or a paid API losing money every minute it's down benefits from checking more often than a marketing page does. Match the interval to what a few minutes of undetected downtime would actually cost you, not to what sounds impressive.
Avoiding false alarms
A single failed check is not proof of an outage — it can just as easily be a transient network blip between the probe and your server. Alerting on the first failure trains people to ignore alerts, which is worse than not alerting at all.
The fix is a consecutive-failure rule: only fire an alert after two or three checks in a row fail, and ideally from more than one probe location, so a routing problem on one path doesn't get mistaken for your site being down. This turns uptime monitoring from a noisy source of false positives into something people actually trust and act on.
What "up" should really mean
A status code alone is a weak definition of "up." A site that returns 200 in 11 seconds is technically up and practically broken for anyone who gave up waiting. A response-time threshold, checked separately from the pass/fail status, catches the slow-but-technically-alive case that a binary check misses entirely.
Content matters too: a 200 response with a database error printed on the page, or a blank page where content should be, passes a naive status check while failing every real user. Checking for expected content in the response — not just the response code — closes that gap.
Why more than one probe location matters
Checking from a single vantage point doesn't just risk one kind of false alarm — a routing blip between that probe and your server — it also misses outages that are real but regional: a CDN edge node failing in one part of the world, or a DNS resolver that only some visitors use returning a stale answer. A check that only ever asks "is the site up from this one place" can't tell a global outage from a local one.
Checking from a few different probe locations catches both problems at once: it rules out "it's just this one path" before alerting you, and it can reveal an outage real for a meaningful slice of visitors even if it isn't global. A single healthy check just means the site is up from where you happened to look.
Setting up a first check
Start with the URL a real visitor hits first, set the interval to match how much undetected downtime you can tolerate, add a response-time threshold, and require at least two consecutive failures before an alert fires. Then verify the alert actually works — point the check at a URL you know will fail and confirm it lands somewhere someone will see it — before trusting it for real.
What uptime monitoring alone won't catch
A passing uptime check means the URL you're watching responded correctly — it says nothing about pages you're not checking, background jobs that silently stop running, or a certificate that's about to expire next week. Uptime monitoring is the foundation, not the whole picture: pair it with checks for TLS and domain expiry, and with heartbeat-style monitoring for anything that runs on a schedule rather than responding to a request, like backups or cron jobs.
How Holter does it
Holter's outside-in checks run from multiple probe locations on the schedule you set, and support a response-time threshold alongside the pass/fail check so a slow site gets flagged, not just a dead one. Alerts can require consecutive failures before firing, so a single transient blip doesn't page anyone.
The free plan covers 5 monitors with 5-minute checks and no credit card — enough to put a real uptime check, plus TLS and domain-expiry checks, on a site's core URL today, before deciding whether you need anything faster or more elaborate.
Holter watches this for you: outside-in monitors plus dead-man heartbeats for silent failures. Free plan: 5 monitors, 5-minute checks, no credit card.
Set up an uptime check — free