A monitor that pings your client's homepage every five minutes from a single data centre tells you one thing: that data centre could reach that page at that moment. It does not tell you the site is up for the people who pay for it. If you promise clients uptime, or even just send them a report with an uptime number on it, the way you measure deserves more thought than a free plugin's default.
What one ping from one region gets wrong
Start with the failure modes of the single-probe setup.
False alarms. A single probe fails for reasons that have nothing to do with your client's server: a routing problem between the probe and the host, a blip at the monitoring vendor, a DNS resolver having a bad minute. You get a 3 a.m. alert, you check, the site is fine, and after three of those you start ignoring alerts. That is worse than having no monitoring, because you have trained yourself to miss the real one.
Missed outages. The reverse is just as real. A CDN edge node in one region can fail while your probe, sitting in another region, sees a healthy site. A regional DNS problem can make the site unreachable for one country only. Your dashboard says green, your client's customers in that country are looking at an error page, and the client finds out before you do.
Blunt timing. With a five-minute interval, a site can be down for four minutes and fifty-nine seconds and never register. Do the maths for a real month. Thirty days is 43,200 minutes, so 99.9% uptime allows 43.2 minutes of downtime (43,200 × 0.001). A monitor that checks every five minutes cannot even resolve a 4-minute outage, and it can be off by up to five minutes on both the start and end of each incident. Against a 43-minute budget, that is not a rounding error.
What "down" should mean
The fix is not just more probes. It is a rule for when a failure counts.
A sensible rule: an incident opens when checks from multiple regions fail, not when one does. If two or more of your probe locations cannot load the page, the odds that the problem is really at the site or its DNS are far higher. If one location fails and the others are fine, log it as a regional anomaly and watch it, but do not wake anyone.
That single change removes most of the false alarms and still catches the regional failures, because you can see which regions are affected. Regional detail is useful on its own. "Down from Frankfurt and London, fine from New York" points straight at a DNS or CDN problem and saves you an hour of checking the wrong thing.
Check the thing that matters, not just the status code
A 200 response does not mean the site works. A WordPress site can return 200 with a white page, a PHP error printed in the body, a maintenance screen that was left on, or a login form where the checkout should be.
Improve the check in three ways:
- Assert on content. Look for a string that only appears when the page renders properly, such as the footer text or a known heading.
- Check more than the homepage. The homepage is often cached and survives when the database is dying. Add a page that exercises the database, and for stores, the cart or checkout page.
- Watch response time as well. A page that takes 12 seconds to respond is technically up and practically down.
Interval, placement, and alerts
Shorter intervals cost more in probes and in noise, so pick a level that matches what the client is paying for. A 60-second check means the worst-case detection delay is about a minute plus whatever confirmation step you add. A five-minute check means up to five.
For a store taking orders, ten minutes of undetected downtime is a real loss. For a brochure site for a local dentist, five minutes is fine. The point is to choose on purpose, and to make sure you are not sold "monitoring" that turns out to be a five-minute ping from one place.
Uptime numbers in client reports
If you put an uptime percentage in a client report, the client will read it as a promise. Two habits help.
First, publish the method in one line: "checked every 60 seconds from several regions; an incident counts when at least two regions fail." A number without a method is a number you cannot defend.
Second, separate causes. If the outage was a host problem, a DNS change the client made, or a plugin update, say so. An uptime figure that lumps everything together makes you look responsible for things you could not control, or hides the ones you could.
One more mistake worth naming: running the monitor on the same infrastructure as the sites. If the host has a network incident, the monitor goes down with the sites and says nothing. External monitoring, from providers unrelated to the host, is the only kind that can report on the host's failures.
The same reasoning applies to who gets the alerts. Route them somewhere you will see them, with a fallback contact, and keep the client out of the first line. A client who receives raw alerts learns to worry about every one of them.
What this looks like in practice
WPClientHub checks uptime every 60 seconds and confirms an outage with a recheck before it alerts. It runs from a single region today; more regions are on the roadmap, and until then a standalone multi-region service is the right choice if a client's contract needs region quorum. What matters is that the method is written down and that it fits the client's stakes.
Where this leaves you
Treat a single-region five-minute ping as a starting point, not as evidence of uptime. Use multiple regions to confirm an incident, check content rather than status codes, and state your method next to any number a client sees. If you want 60-second checks with a confirm-and-recheck rule on a real client site, WPClientHub is free for 3 sites.