How often should you check a website?

The instinctive answer is "as often as possible". It is also the one that fills inboxes and gets monitoring turned off after three weeks. The right interval does not follow from the technology: it follows from what an hour of downtime costs you, and from how fast you can act.

The intervals, and what they actually buy

The second column is the one people forget: with an hourly interval, an outage starting at random lasts half an hour on average before anyone sees it. That is not an hour, and it is not zero either.

Start from the cost, not the technology

The useful interval is the one that keeps the outage shorter than what it costs you. Three cases cover most situations:

Once a day: a showcase site, a portfolio, a blog that is not actively sold against. An outage detected the next morning is annoying, not expensive. Daily checking catches the certificate that expired and the site that has been down for three days without anyone noticing. That alone justifies it.

Every hour: anything that generates leads or bookings. An hour of loss is absorbable; a day is not. This is the right setting for most professional sites.

Every fifteen minutes: a shop, a service under commitment, a site where somebody would say "we lost sales". Below that, the gain becomes theoretical for most businesses.

If you lack the figure to decide, it takes five minutes to work out: what an hour of downtime really costs is the only input this choice depends on.

The question that actually decides

Not how fast can I know, but how fast can I act.

If the person able to fix it is asleep, an alert at 3am and an alert at 7am lead to the same repair time. Checking every minute then buys nothing but four hours of ruined sleep. If someone is on call, the calculation reverses.

Choose the interval that matches your capacity to respond, not your anxiety. An interval shorter than your reaction time is attention spent for nothing.

There is a second version of the same question, and it is the one that settles weekends: who is allowed to act? A monitoring setup that wakes a single person who happens to be on a plane has the same reaction time as no monitoring at all. The interval is a technical setting; the reaction time is an organisational one, and the second is almost always the binding constraint.

What an availability percentage means

Availability figures are quoted everywhere and understood nowhere. They become readable the moment you translate them into minutes.

Two practical consequences. First, a 99.9% commitment allows a forty-minute outage every month with nothing owed to anyone, which is a great deal more than most people picture when they read that figure. Second, measuring 99.9% availability with an hourly interval makes no sense: you would not see the outage that consumes it.

The simple rule: your checking interval should be at least twice as short as the smallest outage you claim to measure.

Checking from one place, or from several

A single check answers "is my site responding to that machine". That is not quite the same question as "is my site responding to my visitors".

Two real gaps exist. A regional network incident can make a site unreachable from part of the world and perfectly reachable elsewhere. And some sites answer differently depending on where the request comes from, for instance when a bot protection filters address ranges.

That said, for the great majority of sites, one well-tuned probe beats three badly confirmed ones. The gain from multi-location checking is mostly about telling an outage of your site from an outage of the path to it, and that is a distinction you need a few times a year, not every day.

What the interval does not solve

Three common failures escape this question entirely, and it is better to know before tuning anything.

The slow but living site. It answers in eight seconds. No availability check flags it, since it answers. The visitor, meanwhile, has left. That is watched with a response-time threshold, not with a frequency. A page that takes eight seconds is, for most visitors, indistinguishable from a page that never loads, and it will never appear in an availability report.

The partial outage. The homepage is fine, the order form returns an error. A check that only looks at the homepage declares the site up, and it is technically right. It is also the kind of failure your host will never mention, for the same reason.

The expired certificate. The server answers perfectly, the browser refuses to display. Checking every minute changes nothing: it is a date that has to be read, not a response.

Maintenance windows

This is the leading cause of alerts people end up ignoring. A nightly backup that puts the site into maintenance for four minutes produces one alert a night, at a fixed hour, until nobody reads them any more.

Two possible answers, and the second is better. Declaring a window during which checks do not raise alerts fixes the symptom. Returning a proper 503 during maintenance fixes the cause: monitoring understands it is a deliberate refusal, and that is exactly what the code means.

Confirmation matters more than frequency

A slow response, a network hiccup, a server restarting for thirty seconds: none of these is an outage. The more often you look, the more of them you catch.

That is why a single failed check should never send an email. The rule that works everywhere: two consecutive failures, or better, two failures from two different places. A real outage passes that test without difficulty; a network hiccup does not.

It is also why the interval matters less than people think. Going from an hour to five minutes without confirmation multiplies false alarms by twelve, and wastes far more time than the fifty-five minutes it saves. That setting deserves treating on its own.

In practice

Pick the interval per site, not globally. Give the shop fifteen minutes and the archived blog a day. You will get fewer emails, and you will read the ones you get, which is the only outcome that matters here.

As soon as the estate runs past a handful of sites, that rule becomes a method: group by criticality, set the interval per group, and accept that most sites do not need looking at often. That is the heart of running an estate, and it is what separates a list of sites from a usable dashboard.

One exception is worth knowing, because it escapes everything above: a certificate expiry date does not change from one hour to the next. One check a day is plenty, and what needs watching is not the renewal job but its result: the three ways it fails in silence.

And if you are still weighing writing your own check against buying an outside service, the interval is not what decides it: the honest comparison is elsewhere.