WordPress uptime monitoring: what it catches, and what it misses
Short answer
Uptime monitoring checks, every few minutes, that a page of the site answers. It catches a site that is down. It misses a page that loads but doesn’t work (a form that no longer sends, a checkout error), errors in the admin or in scheduled tasks that visitors never see, and problems that haven’t happened yet, such as plugins that will break on the next PHP version. Use uptime monitoring for outages, and add log checks and a code check for the rest.
What uptime monitoring does
A monitoring service requests a page of the site every few minutes, from outside, and alerts you when it doesn’t answer, or answers with an error. It is simple, cheap, and catches the problems everybody notices: the server is down, the domain expired, the host has an outage.
What it misses
A page that loads but doesn’t work
The home page answers; the contact form doesn’t send; the checkout fails at the payment step. A monitor that only requests the home page sees a perfectly healthy site.
WordPress’s own error page
Since WordPress 5.2, when PHP stops with a fatal error, WordPress shows a message instead of a blank page and emails the administrator (make.wordpress.org). Depending on what the monitor checks, that page can still count as “the site answered”. If your service can look for a word on the page, choose one that only appears when the page works, such as a word from your footer.
Errors visitors never see
A broken admin screen, an import that fails every night, a scheduled task that stopped: none of them makes the public pages go down. They show up in the error log, not in uptime statistics. The WordPress debug log and the host’s PHP log are where to look, regularly.
Problems that haven’t happened yet
Monitoring watches the present. It can’t tell you that half the plugins on a site will stop working when the host moves it to a newer PHP version, and those moves come on known dates: PHP 8.2 gets security fixes until 31 December 2026, 8.3 until 31 December 2027 (php.net). The only way to see those problems coming is to check the code for the next version before the switch.
A monitoring setup that covers more
| Question | How to answer it |
|---|---|
| Is the site up? | Uptime monitoring, checking for a word on the page |
| Do the forms and checkout work? | Try them after every update day; some monitoring services can run a scripted check |
| Are there new errors? | The PHP error log, read weekly (the maintenance checklist) |
| Will it break on the next PHP version? | A code check for that version, every quarter, and after big updates |
The last row is the one most agencies don’t have, and the one that decides how calm a host’s PHP upgrade announcement will be. Testing a PHP upgrade on staging covers the rest of that work.
Key takeaways
- Uptime monitoring tells you the site answered, not that it works.
- It misses broken forms and checkouts, errors in the admin, failed scheduled tasks.
- WordPress can show a friendly error page that still looks like an answer, so check what the monitor actually tests.
- It can’t see future problems: plugins that will break when the host moves the site to a newer PHP version.
- Add the error log and a regular check for the next PHP version to your monitoring.
Frequently asked questions
Is uptime monitoring worth it?
Yes, it’s cheap and catches outages within minutes. Just don’t mistake it for knowing the site works.
Can uptime monitoring detect a critical error?
Only if it checks for something on the page, such as a word that appears on every working page. A monitor that only checks that the server answered can miss WordPress’s error page.
How do I know a site will survive a PHP upgrade?
By checking the plugins’ and theme’s code for that PHP version before the switch, and testing on a staging copy. Monitoring the live site can only tell you afterwards.
Check your own site before you upgrade
CompatNav is a free WordPress plugin. It reads the code of your plugins and themes on your own server and tells you, in plain words, what will break and what will only show notices on the PHP version you choose. It never changes your code. It can’t see problems that only appear while code runs with real data, so a quick check of your site after the upgrade still matters.
Sources
About the code examples: each output is the real output of the code shown, run with the official PHP builds, without a php.ini, with all errors reported and displayed. Only the file path was replaced by a neutral server path.