WordPress monitoring: 7 things that break

A WordPress site rarely fails in a way that a plain “is the server answering?” check understands. The server answers. It answers with a polite error page, a half-rendered theme or a login form that nobody can reach, and it often does so with HTTP 200.

These are the seven failures we see most often on client sites, with the check that catches each and the first move to fix it. A ready-made set of five checks is in the companion post; this one is organised by what breaks.

1. The database is gone and WordPress says so politely

What happens: MySQL restarts, runs out of connections or loses its disk. WordPress renders “Error establishing a database connection” and returns it with a normal status code.

Detect: a keyword check on the home page that requires a phrase from the healthy page and forbids Error establishing a database connection. A keyword monitor reads the raw response body, so both rules work without a browser. See keyword monitoring.

First move on the server:

systemctl status mysql          # or mariadb
wp db check                     # WP-CLI, run from the site's directory
df -h /var/lib/mysql            # a full disk stops MySQL

2. A plugin update ends in a fatal error or a white screen

What happens: a plugin or theme update is incompatible with the PHP version or another plugin. The page is either blank with status 200, or a 500. On shared hosting a traffic spike can also produce 503 or 508 “resource limit reached” pages.

Detect: status code plus a keyword that must exist in a healthy page, such as wp-content, which appears in the asset URLs of every properly rendered WordPress page. A blank page contains no such string.

First move: disable plugins without the dashboard.

wp plugin deactivate --all
wp plugin activate woocommerce        # re-enable one by one, starting with the essentials

Without WP-CLI, rename wp-content/plugins to plugins-off over SFTP. If that restores the site, rename it back and rename the individual plugin folders until you find the one at fault.

3. wp-cron stops and scheduled work silently dies

What happens: WordPress runs scheduled tasks when someone visits. On a quiet site, or one where DISABLE_WP_CRON was set without a replacement, scheduled posts, backups, order emails and stock syncs just stop.

Detect: a heartbeat monitor. A scheduled task pings a URL every few minutes and you are alerted when the pings stop. Heartbeats start on the Starter plan; the cron monitoring guide has the full pattern.

First move:

wp cron event list              # what is scheduled, and what is overdue
wp cron event run --due-now     # run overdue events once

If you disabled wp-cron on purpose, make sure a real cron entry runs wp cron event run --due-now every few minutes.

4. The cache serves the wrong page to everyone

What happens: a page cache or CDN stores something it should not: a logged-in admin bar, an empty cart, a “we’ll be right back” maintenance page, or a redirect loop. Visitors see it until the cache is cleared.

Detect: keyword checks on the pages that matter (home, shop, checkout), and look at the response headers. The HTTP headers tool shows cache-control, age and typical CDN headers such as cf-cache-status. An age of several hours on a page that should be dynamic is the clue.

First move: purge the page cache and the CDN, then find out what made the page cacheable. Cart, checkout and account pages must be excluded from caching.

5. Nobody can log in, including you

What happens: a security plugin rate-limits the login, a firewall rule challenges every request, or an update renames the login URL. The public site is fine and the client cannot publish.

Detect: monitor /wp-login.php (or your custom login URL) with a keyword such as user_login. If a WAF blocks the monitor, allow-list it first; the Cloudflare allow-list guide shows how, and the checker IP list has the addresses.

6. The certificate or the domain expires

What happens: renewal automation breaks quietly and browsers show a full-page warning, or the domain lapses and the site becomes a registrar parking page.

Detect: SSL and domain expiry monitors with alerts at 30, 14 and 3 days. Both start on the Starter plan. See the SSL expiry guide for the inventory approach and the one-line openssl check.

7. The site is hacked and still returns 200

What happens: a vulnerable plugin lets an attacker add spam pages, inject links into the footer or redirect mobile visitors. The site stays up and looks normal to its owner for weeks.

Detect: two things together. A keyword rule that must not contain words that have no business on the page (pharma, casino, or the name of a known spam network seen in your logs), and a change monitor on the home page that alerts when its content changes unexpectedly. Change detection starts on the Starter plan; see web change detection.

First move: take a backup before changing anything, compare core files with wp core verify-checksums, and update or remove the vulnerable plugin. Then rotate admin passwords and keys.

Choosing the right keyword for each check

A keyword check is only as good as the phrase you choose. Use a phrase that is in the page when everything works and absent when anything is wrong:

Avoid phrases that change often, such as a news headline or a date, or the check fails every time the editor publishes.

False alarms and who gets the alert

Plugin updates, nightly backups and cache rebuilds can make a site slow for a minute. Two settings keep the noise down: a second check that confirms a failure before an alert goes out, and a maintenance window around planned work, so a scheduled update does not count as downtime. Send the first alert to you, not the client, and add the client as a contact only after you trust the setup.

The minimum set per client site

If you only create a handful of monitors for each site, make them these:

1. Home page: status code, required text, forbidden error strings (covers 1, 2, 4).
2. Money page (checkout, booking): same.
3. Login page keyword (5).
4. A heartbeat for wp-cron (3).
5. SSL and domain expiry (6).
6. Change detection on the home page (7), where your plan includes it.

That is six monitors, so a portfolio of 40 sites is 240. On Tenium that fits the Pro plan (300 monitors, $29 a month); the Free plan covers 30 monitors with HTTP and keyword checks, and Starter ($7) adds the heartbeat, SSL, domain and change checks. The WordPress monitoring page describes the full set, and if you also use a WordPress management suite, the Tenium vs ManageWP comparison explains how the two fit together.

Frequently asked questions

Related

Related Tenium pages

• WordPress monitoring
• Free HTTP headers tool
• Tenium vs ManageWP
• All blog posts
• Pricing