How uptime monitoring works

A network switch on a metal shelf inside a dim server cabinet, a row of small green indicator lights along its front edge, with coils of grey and yellow patch cables looping through the foreground.

Nobody wants to learn their website is down from a customer. That is usually how it happens, though: an email that says “is your site working? I get an error,” sent an hour or a morning after the site actually stopped answering. Uptime monitoring is the arrangement that reverses the order, so you hear it from your provider instead.

What a monitor actually does

A monitor is a machine somewhere else on the internet that asks your site for a page on a schedule and writes down what came back. That’s the whole idea, and the simplicity is deliberate.

The somewhere-else part is what makes it work. Your own browser is a poor judge of whether your site is up, because it’s got the page cached and your computer has the address cached, and your office network may route around the exact failure a customer three states away is hitting. Plenty of sites look fine from the owner’s desk while being unreachable for everybody else.

What the monitor writes down is simple: did the server answer, how long did it take, and was the answer the right one. That last question does more work than it looks like it does. A server can respond instantly with an error page, which counts as answering and is still a broken site to the person trying to buy something.

Why detection is never instant

Monitors check on an interval, so there’s always a gap between the moment a site breaks and the moment anyone knows. Shorten the interval and you shorten the gap. You also multiply the false alarms, because the internet drops packets for a living and a single failed request proves very little.

So a sensible setup confirms before it raises an alarm. One failed check is a maybe; the same failure again, ideally from a second location, is real. A monitor that fires on every timed-out request gets muted inside a week, and once it’s muted you’re paying for a service that has stopped protecting you.

What the percentages mean in minutes

Uptime gets quoted as a percentage, which is a strange unit for something you experience as an outage on a Tuesday. Convert it and the numbers get honest. Over a thirty-day month, 99.9% uptime permits about 43 minutes of downtime. 99% permits about seven hours. That’s the same arithmetic every host is doing when they print the figure on a pricing page.

Three questions make any such number mean something: measured by whom, checked how often, and does planned maintenance count against it. If nobody outside the company can verify the figure, it belongs on the pricing page and nowhere else. What you can actually use is a monitor you or your provider control, reporting on your own site.

What monitoring does not catch

A basic monitor asks for one page and is satisfied when that page answers. Plenty of expensive failures never touch that page.

The site is up and the checkout is broken. The home page returns perfectly while a payment step throws an error. Every monitor watching the front door reports green.

The forms stopped emailing. The contact form still says thank you, and the notification quietly goes nowhere. Nothing about the page load reveals it, which is its own topic: mail that vanishes on the way out fails silently by design.

The certificate expired. The server answers fine, but browsers now show a full-page security warning before anyone reaches the site. To a plain up-or-down check this looks like a working site.

The site got slow rather than dead. Pages that take fifteen seconds are technically up and practically abandoned. That’s a measurement problem rather than an availability one, and it’s what the Core Web Vitals numbers are for.

Up-or-down checking is the starting point rather than the finished job. Watching a page that exercises something real, tracking certificate and domain expiry dates, and confirming that mail still leaves the building will each close one of the gaps above.

Who is going to read the alert

An alert is only worth having if somebody acts on it. That’s the question worth asking before you buy monitoring: who does the alert actually reach, and can that person do anything about it. Bolted onto a site nobody maintains, monitoring produces a well-documented outage and nothing else.

On the sites we look after, monitors run around the clock and the alert comes to us rather than to you. Finding out from your own provider instead of your own customer is the whole point of the arrangement. It’s part of the hosting and site care we run rather than an add-on line item.

Keep reading

  • Reading a Lighthouse report without panic

    What one Lighthouse run actually measures, why the mobile and desktop scores disagree, and how to tell which findings deserve action, walked through on our own report.

  • Core Web Vitals, explained for owners

    What LCP, INP, and CLS actually measure, why the score out of 100 is not your Core Web Vitals, and which parts of a performance report are worth acting on.

Site went down quietly?

Monitoring is part of every hosting setup we run. Tell us where the site lives and we will look at what is watching it.