Website Downtime Monitoring

Downtime monitoring vs. uptime monitoring

They run on the same mechanism — a scheduled check from outside your infrastructure — but downtime monitoring puts the emphasis on speed of detection and quality of the alert. A tool can technically "monitor uptime" while doing a poor job of downtime monitoring, if it checks rarely, alerts on noise, or routes alerts nowhere anyone reads.

The practical question isn't "does this check my site" — most tools do that. It's "how long between my site going down and a human finding out," and "does that alert reach someone who can act on it."

What actually causes downtime

Most outages trace back to a handful of causes: a DNS problem, an expired TLS certificate, an expired domain, the host or server itself failing, or a bad deploy that broke something without throwing a clean error. Each of these needs a slightly different check to catch reliably — a plain uptime ping catches a dead server, but not an expiring certificate three weeks out.

That's why downtime monitoring, done properly, is a small set of checks rather than one: uptime, TLS expiry, domain expiry, and DNS resolution together cover the causes that account for most real-world outages.

How fast is fast enough

The honest answer is "faster than your users notice and complain." A 5-minute check interval means a worst case of a 5-minute gap between an outage starting and a check catching it — reasonable for most sites, and the interval Holter's free plan runs on. Anything customer-facing and revenue-critical benefits from a faster interval and a shorter grace period before alerting.

Detection speed only matters if the alert reaches someone. A monitor that fires into a channel no one watches, or an inbox filtered into a folder, adds detection latency of its own — sometimes longer than the outage itself.

Mistakes that delay detection

Checking from one location only. A single vantage point can't distinguish "the site is down" from "this one network path is down" — checking from a few probe locations rules that out before an alert fires.

Alerting on the first failure. This produces so many false positives that people start ignoring alerts entirely, which defeats the purpose of monitoring in the first place.

No owner for the alert. An alert that lands somewhere unmonitored is functionally the same as no alert — the outage still gets discovered by a customer first.

Only checking the homepage. If checkout, login, or an API path fails independently, a homepage-only check won't see it.

Downtime that never touches the homepage

Not all downtime looks like a dead website. A cron job that stops running, a queue worker that silently dies, or a nightly backup that fails partway through can all go on for days without a single outside-in check ever failing, because nothing about the homepage changed. These need a different kind of monitoring: a heartbeat, where the job itself checks in on success (or explicitly reports failure), and an alert fires the moment an expected check-in doesn't arrive on schedule.

Downtime monitoring that only watches the front door misses this category entirely. A site can look perfectly healthy to every visitor while a backup silently stops working underneath it — and the first sign of trouble is discovering, during an actual emergency, that there's no recent backup to restore from.

After the alert: measuring how long it actually took

Detecting downtime fast is only half the job — the other half is knowing, after the fact, how long an incident actually lasted and how quickly it was caught. A monitor's incident history answers both: when the first failed check happened, when the alert fired, and when things recovered. Reviewing that after a real incident is how a consecutive-failure threshold or a check interval gets tuned over time, instead of being set once and never revisited.

How Holter does it

Holter runs outside-in checks — uptime, TLS, DNS, domain expiry — from multiple probe locations, alongside inbound heartbeat monitors for crons, queues, and backups that need to check in rather than respond to a request. An incident opens the moment a check fails past your consecutive-failure threshold, or an expected heartbeat goes missing, alerting the channels you've configured.

The free plan covers 5 monitors with 5-minute checks and no credit card, enough to put real downtime detection — outside-in and heartbeat — on a site's core URLs and background jobs today.