How to monitor a WordPress site's uptime

WordPress runs a colossal share of the web, which means its failure modes are famous enough to have names. The good news: they are also predictable enough to monitor precisely. This guide sets up outside-in monitoring for a WordPress site (or a folder full of client sites) that catches the database error, the broken plugin update and the silently failing backup, not just the unplugged server.

How WordPress sites actually go down

WordPress outages rarely look like a dead server. The stack has several moving parts (PHP, MySQL, a theme, a stack of plugins, a host's resource limits), and most failures leave the web server politely serving an error page:

The database error appears when MySQL is down, out of connections or misconfigured; the critical-error page is a fatal PHP error, which in practice usually means a plugin or theme update that went wrong. Add the other regulars: a host suspending the site at a resource limit, a caching layer serving a broken page forever, a certificate quietly expiring, and the backup job that stopped running months before anyone needed it. Different causes, one common thread: from the outside, most of them still answer.

Why a ping isn't enough

A basic uptime check asks “did the server respond?”. For WordPress that bar is too low: the interesting failures respond fine. What you want to know is whether the site is serving your content, and that means reading the page:

A keyword check does exactly this. It fetches the page like a visitor and asserts two things: text that should always be there is present (a footer line, your company name), and text that should never be there is absent (Error establishing a database connection, There has been a critical error). With both assertions in place, every famous WordPress failure page becomes a detected outage instead of a quiet 200.

What to monitor on a WordPress site

You don't need twenty checks. Six cover the whole stack, each proving something the others can't:

The inner page matters more than it looks: a cached homepage can survive a dead database for hours, while a real post or service page has to touch PHP, the theme and the permalink rules. The /wp-json/ REST index (on by default; skip it if a security plugin disables it) is the closest thing WordPress has to a health endpoint. Running WooCommerce? Add a keyword check on the checkout page; it's the page that pays for the others.

Set it up, step by step

1. 1

   Create a keyword check on the homepage

   In the new-monitor dialog, choose the keyword type, point it at https://www.example.com and require a string that lives in your footer. Then add the negative twin: alert if Error establishing a database connection appears.

2. 2

   Add the inner page and the REST index

   A keyword check on one real inner page (assert on text unique to it) and an HTTP check on /wp-json/ expecting a healthy response. Three checks now cover cache, database, theme and the application layer.

3. 3

   Set the interval

   Every 60 seconds is the sweet spot for most sites (paid plans go to 30). Failures are confirmed before anyone is alerted, so a tight interval buys speed, not noise.

4. 4

   Route the alerts

   Email, Slack, Teams, Telegram, Discord, SMS or a webhook. Agencies: route client sites to the channel the account team reads, and turn on recovery notices so “it's back” arrives as automatically as “it's down”.

5. 5

   Add the expiry checks

   An SSL check and a domain check on the site's hostname take two minutes and remove the two most avoidable disasters in hosting. Details in the section below.

6. 6

   Rehearse one failure

   Temporarily require a keyword the page doesn't contain, watch the alert arrive where you expected it, then put it back. Two minutes now beats discovering a dead alert channel during a real outage.

The jobs wp-cron pretends to run

WordPress schedules its background work (backups, scheduled posts, update checks, WooCommerce emails) with wp-cron, and wp-cron has a famous catch: it only fires when someone visits the site. A quiet site means late or skipped jobs; a busy site means the work runs mid-request at random. The standard fix is to disable the fake cron and run the real one:

# wp-config.php: stop WordPress firing cron on page views
define( 'DISABLE_WP_CRON', true );

# crontab: run it properly every 5 minutes, then ping the heartbeat
*/5 * * * * curl -fsS -m 20 "https://www.example.com/wp-cron.php?doing_wp_cron" \
  && curl -fsS -m 10 https://app.247monitor.net/api/v1/heartbeat/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6

The last line is the part most setups miss. Chaining a heartbeat check onto the cron command (or onto the backup plugin's own hook) means silence becomes an alert: if the job stops running for any reason, you hear about it that night, not at restore time. Backups are the classic case, because a backup that silently stopped is indistinguishable from a working one until the day it matters.

The quiet expiries: SSL and domain

Two failures take down more small sites than any plugin: the certificate expires, or the domain registration does. Both are entirely predictable and both fail silently until the morning everything stops. A dedicated SSL check reads the certificate actually being served and warns you 30 days out by default, catching the renewal that didn't reload as well as the one that didn't run. A domain check does the same for the registration itself, with weeks of notice instead of a seized homepage. One of each per site, and two whole categories of emergency become calendar items.

Updates without 3am surprises

WordPress core ships minor updates automatically, and plugins can auto-update too, which means your site can change at any hour without a human involved. Monitoring is the safety net that makes that tolerable:

• Let the update window breathe. During updates WordPress briefly shows a maintenance page. Confirmation and consecutive-failure rules mean a 30-second window passes silently, while an update that actually breaks the site alerts within a minute or two.
• Update deliberately when you can. For the changes you control, update a staging copy first, and do production inside a scheduled maintenance window so monitors stay quiet on purpose rather than by luck.
• Watch the page that earns the money. The homepage often survives an update that breaks a form, a checkout or a booking flow. That's what the inner-page and checkout keyword checks are for.

Frequently asked questions

Six outside-in checks, one heartbeat on the jobs, and a rehearsed alert path: that's WordPress monitoring that catches the database error, the broken update and the backup that quietly stopped. 247Monitor's keyword, heartbeat, SSL and domain checks cover all of it, with 25 monitors free; the general website uptime guide picks up where this one ends.