99.9% Uptime Doesn't Mean a Client Site Works

· · Drafted with AI, reviewed by Pavol Bincik · How we write

TL;DR

99.9% uptime still allows 8.76 hours of downtime a year, and an uptime check only asks whether the server answers. A page can answer with a success code while it shows a blank template, a hosting suspension notice or a registrar's "domain expired" page. On client sites, add a keyword check that fails when real content is missing, watch the response time trend, and open the site yourself before you report an outage. Baromio does not run scripted multi-step journeys, so test logins, forms and checkouts by hand after updates.

A client site with "99.9% uptime" sounds safe. That figure still allows 8.76 hours of downtime a year, or about 43 minutes in a 30-day month. And it only counts the time the server did not answer at all.

The bigger gap is what an uptime check calls "up". A site can answer every check and still be broken for the people who visit it.

What an uptime check actually tests

A basic HTTP check asks one question: does the server answer with a status code that means success? It looks at the status code and nothing else. It does not read the page.

So each of these passes as "up", as long as it answers with a success status:

  • a blank page from a broken cache, theme or page builder
  • a hosting provider's "account suspended" or "limit exceeded" page
  • a registrar's page after the domain registration lapsed: after a .com-type domain expires, the registrar has to stop it resolving to your site and may show a renewal page instead
  • a redirect to a page that is itself broken, if the check does not follow redirects
  • a contact form or checkout that loads, but fails when someone submits it

There is also the gap between checks. With a check every 5 minutes, a 3-minute outage can start and end between two checks and never show up in the uptime figure.

Check for content, not just a status code

A keyword check downloads the page and looks for a piece of text. It works in two directions:

  • Fail when the text is missing. Pick text that is only there when the page really works. An empty response, a suspension notice or a registrar's page will not contain it.
  • Fail when the text appears. Pick text that only shows up when something is wrong, such as "Fatal error" or "Database error".

Choosing the text is most of the work:

  • Use text the server sends in the HTML. A keyword check reads the page source, not what JavaScript adds after the page loads.
  • Use text the CMS renders from its content, such as a section heading or the phone number in the footer. Avoid text a static error template might also contain, such as the site name.
  • Avoid text that changes: prices, dates, the title of the latest post.
  • Check the final URL. If example.com redirects to https://www.example.com/, monitor the second one.

One keyword check on the home page and one on the page that earns the client money (the booking page, a shop category, the contact page) cover most of what a visitor would notice.

Slow is not down

An uptime check gives the server several seconds before it records a timeout. A page that takes eight seconds to appear is not "down", but for a visitor it might as well be.

Slowness shows up in two places:

  • The response time of each check. A rising trend after a hosting change or a plugin update is the early sign. It measures how fast the server answers, not how long the page takes to render.
  • A page speed test. Lighthouse, which also powers Google PageSpeed Insights, measures how the page loads in a browser. An uptime check cannot.

Look at both after every update, not only when the client complains.

When "down" is not down

The opposite happens too. Some sites sit behind bot protection that can answer a monitoring service in a data centre differently from a visitor's browser. The monitor then reports the site down while it opens fine for everyone else.

We ran into this in early September 2026: a monitor on a large public website stayed Down through a long incident while the page loaded normally in a browser, and every check from other regions reported it up. Before you call a client about an outage, open the site yourself from a normal connection.

What no uptime check covers

Uptime and keyword checks load one URL. They do not log in, fill in a form, add a product to a cart or pay. Baromio does not run scripted multi-step journeys either.

For a client whose income depends on such a flow, test it by hand after every plugin, theme or payment update: send the contact form to yourself, place a test order, log in with a test account. It takes a few minutes and catches what a URL check cannot.

How to set this up in Baromio

  • HTTP monitor: sends a HEAD request (GET if the server refuses HEAD), counts any status below 400 as up and does not follow redirects. It answers "is the server responding".
  • Keyword monitor: fetches the page with GET and searches the HTML source for your text, ignoring upper and lower case. You choose whether the check fails when the text is missing or when it is found. Give it the final URL, after any redirects.
  • Response time: every check's response time is stored, and the monitor page charts it for the last 24 hours, 7 days or 30 days. There is no alert for "slower than X milliseconds". Alert after sets how many failed checks in a row (1, 2, 3 or 5) it takes before you are alerted, which keeps one-off blips out of your inbox.
  • Regional Disagreement: while an HTTP or keyword monitor is down, Baromio re-checks the site from other locations. If all of them reach it, two cycles in a row, the monitor card shows a DISPUTED badge and the incident page explains why. It never changes the alert or the recovery; it only tells you the Down may be a false alarm. It is on every plan.
  • Page speed: switch on Monitor Page Speed on an HTTP or keyword monitor to run Lighthouse through Google PageSpeed Insights: 1 URL weekly on Free, 5 URLs daily on Pro, 15 daily on Business.
  • Intervals: every 5 minutes on Free (20 monitors), every minute on Pro (9 EUR a month, 30 monitors), every 30 seconds on Business (29 EUR a month, 100 monitors).

A checklist for each client site

  1. An HTTP monitor on the home page.
  2. A keyword monitor on the page that matters most, set to fail when a piece of real content is missing.
  3. A look at the response time chart after every hosting change or larger update.
  4. A manual test of forms, logins and checkout after every update.
  5. Before you tell the client about an outage, open the site yourself.

Sources

  • ICANN, Expired Registration Recovery Policy: after expiry the registrar must interrupt the domain's DNS resolution path; a landing page shown instead must say the registration has expired.