How to monitor WordPress sites without alert fatigue

Short answer: to monitor many WordPress sites without drowning in noise, collect data from each site (versions, plugins, health) instead of only pinging its homepage, sign every request, match installed plugins against a vulnerability feed automatically, and route alerts by severity, with quiet hours and a daily digest. Above all, make the system smart about failure, so one flaky host or a problem on your own network doesn't page anyone.

Looking after one WordPress site is easy. Looking after thirty is a different job: something is always out of date, some host is always having a bad day, and the alert channel fills up until everyone mutes it. I built Fleet Sentinel, as product owner and developer, to solve exactly this. Here are the lessons that shaped it, and they apply whatever tool you use.

1. Check more than homepage uptime

A homepage returning 200 OK tells you very little. A site can be "up" while it is:

• running a plugin with a published critical vulnerability,
• three major versions behind on PHP,
• about to lose its TLS certificate,
• or quietly carrying a new administrator account nobody created.

A fleet monitor also needs information from inside each installation. In Fleet Sentinel, a small agent plugin on each site reports its WordPress version, plugins and themes, administrators, server and PHP details. The panel turns that into automatic findings: vulnerabilities, pending updates, core updates, PHP end-of-life, TLS expiry, site down and agent lost. It also watches for pages that used to work and now fail, tests whether each site's email arrives, and keeps a log of who changed what.

Keep the external uptime check too. It's still the fastest way to know a site is down, and you can use your own prober or an existing service such as UptimeRobot or Better Stack.

The WordPress uptime monitoring guide covers checks designed to catch real visitor-facing failures.

2. Pull, don't just wait for heartbeats

The obvious design is to have every site send a heartbeat every minute. On shared hosting, that falls apart: WP-Cron only runs when someone visits, outgoing requests get blocked, and caching layers swallow requests.

What works better is to have the panel pull data from each site, trying more than one route to reach it:

1. a dedicated, signed RPC endpoint,
2. then admin-ajax.php,
3. then REST API variants,

and remember which route works for each site. Let the agent push small "something changed" nudges as a bonus, not as the only signal. Add cache-busting headers, because many hosts cache anything that looks like a GET request.

3. Sign everything

A monitoring endpoint on a WordPress site is an attack surface. Treat it like one:

• Sign every request with HMAC-SHA256 using a secret created when the site is paired.
• Include a timestamp and a nonce, and reject replays and requests outside a small time window.
• Correct for clock skew, because shared hosts are often a few minutes off.
• Rate-limit the endpoint and compare signatures in constant time.
• Encrypt stored API keys at rest. Fleet Sentinel uses AES-256-GCM.

A simplified version of the verification step looks like this (nonce_was_used() stands in for your own nonce store):

$expected = hash_hmac( 'sha256', $timestamp . "\n" . $nonce . "\n" . $body, $secret );

if ( ! hash_equals( $expected, $signature ) ) {
    return new WP_Error( 'bad_signature', 'Invalid signature', array( 'status' => 401 ) );
}
if ( abs( time() - (int) $timestamp ) > 300 || nonce_was_used( $nonce ) ) {
    return new WP_Error( 'replayed', 'Request expired', array( 'status' => 401 ) );
}

4. Decide "down" with statistics, not a single timeout

The fastest way to create alert fatigue is to page someone every time one request times out. Two techniques made a big difference:

• Classify failures. A timeout, a TLS error, a firewall block and a clock-skew rejection are different problems with different owners. Fleet Sentinel sorts failures into 15 types, so the alert tells you what went wrong.
• Use a φ (phi) accrual failure detector. Instead of a fixed timeout, it learns each site's normal response rhythm and outputs a suspicion level that rises the longer a site stays quiet compared with its own history. You alert when suspicion crosses a threshold. It's the approach described by Hayashibara and colleagues, and it copes well with naturally slow hosts.

One more rule saves a lot of false alarms: if most sites fail at the same moment, the problem is probably you. Hold the alerts and check the monitor's own network first.

5. Turn vulnerability data into action

Vulnerability databases are huge. The Wordfence Intelligence feed that Fleet Sentinel ingests is well over 100 MB, so stream it rather than loading it into memory. Then:

1. match every installed plugin and theme version against it,
2. re-evaluate on a schedule (every 15 minutes works well),
3. and show the result as one prioritised "needs attention" list across the whole fleet, not as thirty separate dashboards.

Group pending updates across sites too. "Update plugin X on 12 sites" is one decision, not twelve.

The WordPress vulnerability monitoring guide covers the path from a vulnerability alert to a fix.

6. Route alerts to the right team

Fleet Sentinel sends these to Google Chat as rich cards titled with the site's name, or to email lists, and the same rules apply to Slack or Teams.

7. Build it to be trusted

Monitoring software handles sensitive site data and credentials. Restrict what it can access and test those boundaries:

• Multi-tenant from day one. Every query is scoped to its fleet, with roles (viewer, editor, admin, superuser) and per-fleet audit logs that fleet admins can't erase.
• Hardened uploads. Content-sniff the file type, refuse SVG, guard against decompression bombs, and re-encode images.
• Tests that cross languages. Fleet Sentinel's end-to-end tests run the real PHP plugin against the TypeScript panel. The project has 2,832 passing Vitest tests and 21 PHP test scripts, and a 500-site load simulation exercises the panel at scale.

Where to start monitoring a small fleet of WordPress sites

You don't need to build a platform on day one. For five to ten sites:

1. Add an external uptime monitor with a sensible retry policy.
2. Subscribe to a vulnerability feed and review it against your plugin list each week.
3. Turn on auto-updates for well-maintained plugins, and follow the hardening checklist.
4. Track performance, because slow checkout pages are an incident too.
5. Automate once the manual routine starts eating your week.