There is a specific kind of message nobody who manages websites wants to receive: a client asking why their site has been showing an error since this morning. At that point the outage is already hours old, the client has lost enquiries or sales, and the first person to notice was the one paying you to notice.
WordPress uptime monitoring is how you make sure you hear first. A monitor checks the site on a schedule, from outside, and alerts you the moment it stops answering properly. This guide covers how often to check, where to check from, what to look for beyond a simple “is it up?”, and how we set it up with WPCentrify.
The message nobody wants to receive
Websites go down for ordinary reasons:
- the host has a hardware or network problem;
- a plugin or theme update causes a fatal PHP error;
- the database runs out of connections or disk space;
- an SSL certificate or the domain itself expires;
- a traffic spike, or a bot, overwhelms the server;
- someone edits a file directly on the live site.
None of these announce themselves to the site owner. WordPress emails the site administrator when it catches a fatal error, but that email often goes to an inbox nobody reads, and it cannot send anything if the server itself is down.
Without monitoring, you find out about downtime in one of three ways: you happen to visit the site, a customer complains, or the client tells you. All three are slow, and the last one costs trust. Website downtime alerts reverse the order. You know within minutes, you can start fixing it, and when the client does notice, you can tell them it is already in hand.
What downtime actually costs
The cost depends on what the site does. A brochure site loses enquiries. An online store loses orders while it is down and often loses the customer to a competitor. A booking site loses appointments. In every case, the fix usually takes the same time whether you start ten minutes in or six hours in; the difference is how long the site was down before anyone started.
How often to check, and from where
Check every 60 seconds
The check interval sets the worst case for how long an outage can run before your monitor notices it.
| Check interval | Longest an outage can run before the first failed check |
|---|---|
| 60 seconds | About 1 minute |
| 5 minutes | About 5 minutes |
| 15 minutes | About 15 minutes |
| 1 hour | About 1 hour |
Five-minute checks are common on free plans, and they are fine for a personal blog. For a business site, a store, or any site you are responsible for on a client’s behalf, check every minute. Short outages matter too: a site that drops out for three minutes several times a day is a sign of a problem on the server, and slower checks may never see it.
Check from more than one region
A single checking location has a weakness: if the network between that checker and your server has a problem, your site looks down when it is not. Alert on every one of those blips and people start ignoring alerts, which is worse than having none.
Multi-region uptime checks solve this. When one location sees a failure, a second location confirms it before anyone is alerted. Checking from several regions also tells you something useful about the outage: if the site is down everywhere, the problem is the server; if it fails only from one region, it may be DNS, a CDN or a routing problem.
Uptime percentages, in minutes
Hosts and monitors talk in percentages. Over a 30-day month, they translate roughly like this:
- 99% allows about 7 hours 12 minutes of downtime.
- 99.9% allows about 43 minutes.
- 99.99% allows about 4 minutes.
Monitoring gives you your real figure, which is useful evidence when you talk to your host about whether they are delivering what they promised.
Beyond “is it up?”: status codes, errors and speed
The most basic monitor asks one question: did the server answer? That misses a lot of WordPress failures, because a broken WordPress site often still answers.
Status codes
Every response carries an HTTP status code, and a good monitor reads it:
- 200 means the page loaded. This is what you want.
- 301 or 302 means a redirect. Expected on some URLs; suspicious on your homepage.
- 4xx codes (403, 404) mean the page is forbidden or missing. A homepage returning 404 is down, as far as visitors are concerned.
- 5xx codes (500, 502, 503, 504) mean the server or something in front of it failed. Treat any of these as down.
Errors that look like pages
Some of WordPress’s most common failures produce a page rather than no answer:
- “There has been a critical error on this website”, after a plugin or theme fatal error;
- “Error establishing a database connection”, when the database is down or overloaded;
- a blank white page, when PHP fails before anything is printed;
- a host’s suspension or maintenance page.
A content check catches these. Tell the monitor to look for a word or phrase that only appears on a working page, such as your business name in the footer, and to treat its absence as a failure.
Speed
A site that takes 20 seconds to load is up in name only. Track response time on every check and alert when it climbs well above normal. A slow, steady rise usually points to a growing database, a plugin doing too much work, or a server running short of resources. It is often the warning before an outage.
Response time is different from the Core Web Vitals visitors experience, which also depend on images and scripts. Both are worth tracking; our Core Web Vitals guide explains the second.
The expiry dates
Two failures are entirely predictable and still catch people out: an expired SSL certificate, which makes browsers show a full-page warning, and an expired domain. Add both expiry dates to your monitoring or your calendar, with a reminder at least two weeks ahead.
Setting it up with WPCentrify
WPCentrify is our own WordPress management platform, and it is what we use to monitor the sites we look after. Uptime monitoring is built in, so there is no separate service to configure for each site.
What it checks
- Every 60 seconds: each connected site is checked once a minute, with instant alerts.
- Confirmed from a second location: a failure is verified from another location before you are alerted, which keeps false alarms down.
- Response time and Core Web Vitals: tracked over time, so you can see a slowdown building.
- One screen for the portfolio: every connected site appears in one list with its current status and recent uptime.
How to set it up
- Connect the site. Install the small WPCentrify connector plugin. It uses a scoped key rather than your admin password, and you can deactivate it from WordPress at any time. The site stays on its current host.
- Choose where alerts go. WPCentrify integrates with email, SMS, Slack, Microsoft Teams and Discord, so alerts reach whoever is on call, in the tool they already watch.
- Decide who responds. Use team access to give the right people the sites they are responsible for.
- Report it. Uptime goes into the white-label client reports that WPCentrify sends automatically, with a plain-language summary at the end of each month, so clients see the work even when nothing went wrong.
Uptime is half the picture
Uptime monitoring tells you when a site stops working. It does not tell you when a site keeps working but has been changed by someone who should not be there. For that, read our guide to WordPress security monitoring, which covers file, administrator and sign-in alerts.
If you would rather not run any of this yourself, monitoring, updates, backups and security are all part of our WordPress management service, which runs on WPCentrify. The platform is free during its early access period, and our WPCentrify page explains how we use it for client sites.