Skip to content

Monitoring5 min read

How to Monitor Dozens of WordPress Sites Without Alert Fatigue

How to monitor WordPress sites at scale: pull-based agents, signed requests, smarter failure detection and alerts nobody mutes.

By Hamza Ahmad AslamFull-Stack & WordPress Engineer

A laptop screen showing blue analytics charts of page load times and bounce rates
Photo by Luke Chesser on Unsplash (opens in a new tab)
On this page
  1. 1. Uptime pings are not monitoring
  2. 2. Pull, don't just wait for heartbeats
  3. 3. Sign everything
  4. 4. Decide "down" with statistics, not a single timeout
  5. 5. Turn vulnerability data into action
  6. 6. Route alerts like a grown-up
  7. 7. Build it to be trusted
  8. Where to start monitoring a small fleet of WordPress sites
  9. Frequently asked questions

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. Uptime pings are not monitoring

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.

Real fleet monitoring needs inside information. 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.

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.

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 14 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.

6. Route alerts like a grown-up

RuleWhy
Minimum severity per channelCritical issues go to the on-call space, while low-severity items wait for the digest
Per-site or fleet-wide routingClient A's alerts go to client A's team
Quiet hoursNobody needs a "plugin update available" message at 3 a.m.
Daily digestThe small stuff arrives in one summary
Delivery log and test alertsYou can prove the alerting itself works
An "all clear" messagePeople can stop worrying when an agent reconnects

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

7. Build it to be trusted

Monitoring software has admin access to everything, so it deserves a high bar:

  • 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 482 passing Vitest tests and 142 PHP checks across 6 suites, 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 (here's how to speed up WooCommerce).
  5. Automate once the manual routine starts eating your week.

Curious how Fleet Sentinel fits together? Read the full project deep dive, or talk to me about monitoring your own sites.

Frequently asked questions

How often should a fleet be checked?

Health and inventory every minute or two is realistic when the panel pulls data. Vulnerability matching every 15 minutes and a daily digest keep the noise down without missing anything urgent.

Is an agent plugin safe to install on client sites?

It is as safe as its design. Insist on signed requests, replay protection, rate limits, no secrets in the browser and a deactivation hook that tells the panel it's leaving.

Can I use this approach without writing code?

Yes. Combine an uptime service, a vulnerability-alert service and a management dashboard. The principles above help you choose and configure them well.

Enjoyed this? Get the next article by email.

Occasional, useful posts. No spam — unsubscribe anytime.