WordPress monitoring: the checks a WordPress site actually needs

A monitor set for one WordPress site

WordPress has no special monitor type, and it does not need one. A solid set is built from the standard types, and for a typical site it takes five to six monitors:

• Keyword on the home page: a footer phrase must be present, and "Error establishing a database connection" must be absent (Starter plan and above).
• HTTP on /wp-login.php with the default 200-299 range, or 200-399 if it redirects to https.
• JSON API on /?rest_route=/ with the path name and your site title as the expected value; this works without pretty permalinks and proves PHP, the database and the REST layer together.
• Heartbeat for scheduled work (next section).
• SSL / domain for the certificate and registration dates.
• Optionally DNS for the A record, or an HTTP monitor that expects 403 on /xmlrpc.php if you have blocked it on purpose.

wp-cron is not a clock

By default WordPress runs scheduled tasks only when somebody visits the site. A quiet site therefore publishes scheduled posts late, sends mail queues late, and skips backups. Worse, a busy one can trigger the same job twice. The fix that most hosting guides recommend is to set DISABLE_WP_CRON to true in wp-config.php and run the task from a real scheduler every five minutes: */5 * * * * cd /var/www/site && wp cron event run --due-now && curl -fsS https://YOUR-APP-HOST/hb/hb_TOKEN. Create a heartbeat with a period of 600 seconds and a grace of 300. Now a missing ping means the actual scheduler stopped, which also explains why backups and scheduled posts went missing.

Heartbeats start on Starter, and the allowances are generous: 20 on Starter and 100 on Pro, so one per site is feasible even for a studio.

The first five minutes after an update

Most WordPress outages begin with a plugin, theme or core update. Three failure screens deserve their own absent-phrase checks, because each can be served with a normal status code by a cache or a custom error template: "There has been a critical error on this website" (the fatal-error screen), "Briefly unavailable for scheduled maintenance" (an update that stalled and left the maintenance file behind), and "Error establishing a database connection". Put them in separate keyword monitors or pick the two you see most; the failure message then names which one appeared.

Pair the checks with a maintenance window when you update on purpose, so a few minutes of deliberate downtime do not alarm the client or ruin the uptime figure in the monthly report.

Caches can hide an outage

Page caches and CDNs are designed to keep serving the last good copy, which is wonderful for visitors and terrible for monitoring. With the database down, a cached home page can stay green for hours. Keep at least one monitor on something that must run PHP and touch the database: wp-login.php is never cached by sensible setups, and the REST root at /?rest_route=/ is dynamic as well. If your cache serves error pages for a while, the absent-phrase check catches those too.

The reverse also happens: a security plugin or WAF treats a monitoring IP as an attacker. Wordfence, Cloudflare rules and fail2ban may all block it after a few requests. Allow-list the checker IP list or send an X-Tenium-Secret header that your rule can match, and the monitor is no longer part of your attack surface. A bot challenge shows up as a "blocked" incident rather than "down".

Running forty sites

At five monitors a site, the Pro plan's 300 monitors cover about 60 sites and Agency's 1000 cover 200. Consistency matters more than cleverness: use the same monitor names (Client A, home keyword), the same tags, and the same alert contacts everywhere, so incidents read the same on the status page and in the report. A CSV import can create the monitors in bulk; the import docs list the columns. On the Agency plan, give each client a workspace with their own viewer login and branded monthly report; see for agencies.

Know the boundary. Tenium looks at your site from outside, so it will tell you the site is unreachable, which a plugin cannot do after the site is gone. It does not see plugin versions, file changes, malware, or backups. Tools like ManageWP and MainWP do that job, and they complement rather than replace this.