Online isn’t the same as working. A WordPress site with a database error still answers a monitor perfectly — the server said “200 OK”, it just served a blank page to your customers. Every site we host is checked every minute, and we read the page we were served, so “working” is what we actually measure.
Every hosted site is a monitor by default — there’s nothing to set up. A check loads your site the way a visitor would and confirms it answered properly.
This is the part most monitoring misses. A broken WordPress site usually still returns a normal “200 OK” — the database error screen, the critical-error page, a stuck maintenance notice, a PHP fatal. We read the page we were served and recognise those failures by name, and we look for the marker our platform writes into every healthy page. A page that came back but didn’t render is an outage, and the alert says which failure we found.
A single failed check is never treated as an outage. We immediately re-check twice, fifteen seconds apart, so a momentary blip never wakes anyone up. Between the check itself and those confirmations, real downtime is usually confirmed within about two minutes.
Checks run from separate regions, far apart. An incident is only declared when more than one observer sees your site down — so a network hiccup near one checker can’t create a false alarm.
When downtime is confirmed we email you (and anyone else you name) with what we saw and when — and again when it’s back, with how long it lasted. No error codes to decode.
Certificates auto-renew, and we monitor expiry anyway. If a certificate is heading toward expiry you get a warning well ahead of the deadline.
Uptime isn’t a promise in a brochure — it’s a screen in your dashboard, any time you want to look.
| Site | Status | Uptime · 30d | Response | Checked |
|---|---|---|---|---|
| yourbusiness.com | Online | 100% | 412 ms | 1 min ago |
| shop.yourbusiness.com | Online | 99.98% | 388 ms | 1 min ago |
We call a site down when it fails to answer, returns a real error (a 404, a server error, a connection failure), or answers with a page that plainly didn’t render — confirmed by re-checks and by more than one region. We do not call a site down because it was slow, and a site behind a login or password wall counts as up: it answered, it’s just private.
The rendered-page check recognises the specific WordPress failures we can identify with certainty — the database-connection error, the critical-error screen, a stuck maintenance page, a PHP fatal or parse error, and a page that came back with almost no content in it. It is not a general “is this page correct?” check: a typo in your copy, a broken image, or a plugin that quietly stopped working will not trigger it. What it guarantees is that the common ways a WordPress site breaks while still saying “200 OK” do not go unnoticed.
Monitoring tells you fast and accurately that something is wrong. Fixing it is our job too — that’s what a care plan is — but the monitor’s promise is specifically: you will know, quickly, and it won’t cry wolf.