Monitoring WordPress Sites

Short answer. WordPress goes down more often than a static site: plugin auto-updates, the "white screen of death," theme conflicts, PHP memory exhaustion. Monitor more than homepage availability (HTTP 200) — also check for an expected keyword on the page, response time, SSL, and the admin login. The best signal is a lightweight health endpoint that checks the database and doesn't depend on a heavy frontend.

Why WordPress needs special attention

WordPress is the world's most popular CMS, but also the most fragile to operate. Typical failure causes that static sites don't have:

• White screen of death (WSOD). A fatal PHP error after a plugin update — the page returns blank with a 500, and sometimes even a 200.
• Auto-updates. WordPress updates core and plugins on its own at night — and by morning the site may not load.
• PHP memory exhaustion. A heavy plugin or a traffic spike hits the memory_limit.
• Expired SSL. Especially on sites where the cert was forgotten after first setup.
• Hacks and redirects. A compromised WordPress often redirects to spam — the homepage "works," but it's not yours.

A 200 status on WordPress doesn't guarantee the site is intact. WSOD and hacked redirects can return 200. Check that the page contains an expected string — like the site name or a footer SNI.

What to monitor on a WordPress site

What to check	Check type	What it catches
Homepage	HTTP 200 + keyword	WSOD, hacks, redirects
Response time	HTTP + ms threshold	Heavy plugins, resource starvation
/wp-login.php	HTTP 200	Admin availability
SSL certificate	SSL monitoring (14/3 days)	Certificate expiry
REST API документацию /wp-json	HTTP + JSON	Is PHP and the DB alive
Cron / WP-Cron jobs	Heartbeat monitoring	Stalled scheduler

A lightweight health endpoint instead of the heavy homepage

A WordPress homepage often fires dozens of database queries and third-party scripts. Monitoring it means catching false alerts on every load spike. Better to add an mu-plugin (must-use plugin) that returns a lightweight health response, checking only the database:

<?php
// wp-content/mu-plugins/health-check.php
add_action('init', function () {
    if ($_SERVER['REQUEST_URI'] !== '/wp-health') return;
    global $wpdb;
    $ok = ($wpdb->get_var('SELECT 1') == 1);
    status_header($ok ? 200 : 503);
    header('Content-Type: application/json');
    echo wp_json_encode(['status' => $ok ? 'up' : 'down']);
    exit;
});

Now a monitor on https://site.com/wp-health expecting a 200 fails exactly when the database dies, not when the homepage merely loads slowly. Check manually:

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://site.com/wp-health

Keyword checks — against WSOD and hacks

The trickiest WordPress failure is when a page returns 200 but the content is broken or swapped. To catch it, the monitor must look for an expected string on the page. If your site name or a footer snippet is gone, something is wrong — even if the status code is "good."

After every plugin or core update, verify that monitoring still sees the keyword on the page. That's your first line of defense against a silent WSOD.

Monitoring WP-Cron via heartbeat

WP-Cron in WordPress runs on page visits and easily stalls on low-traffic sites: emails don't go out, scheduled posts don't publish, plugin backups don't run. Heartbeat monitoring (a dead man's switch) solves this: configure the job to send a "Ping" to enterno.io, and if the ping doesn't arrive on time, you get an alert about a stalled scheduler.

Alerts and multi-region

enterno.io sends alerts via Telegram, Slack, email, webhook, PagerDuty, and Jira. Multi-region checks (Russia, Europe, US) are especially useful for WordPress: hacked sites sometimes show a spam redirect only to visitors from certain countries. Checking from different regions exposes this.

FAQ

Why does status-200 monitoring miss the white screen of death?

Because WSOD and hacked redirects can return 200. Add a keyword check on the page — it catches broken or swapped content.

How do I monitor a site after plugin auto-updates?

Check every minute (Pro plan) and always with a keyword. Then a crash after a nightly auto-update is caught right away, not from a client complaint.

Should I monitor /wp-admin?

It's useful to monitor /wp-login.php availability — if it's down, you can't fix the site. But the main focus is the public side and the health endpoint.

How many monitors does one WordPress site need?

At least 3: homepage (with keyword), SSL, and a health endpoint. The free enterno.io plan allows up to 10 monitors — enough for 2–3 sites.

Start monitoring — free →

See also: the full website monitoring guide, designing health-check endpoints, and SSL certificate monitoring.