Your Cache Can’t See the Server: What to Monitor Below WordPress
A good cache plugin makes a WordPress site feel fast, even on a tired server. That’s also the catch: the cache hides the server’s warning signs until uncached traffic piles up and the site falls over. Here’s what to watch below the cache, which signals deserve an alert, and how agencies with dozens of client sites keep tabs on all of them.
What the Cache Covers and What It Skips
A page cache stores finished HTML and serves it without running PHP or touching MySQL. For an anonymous visitor reading a blog post, that’s the whole job, and it does it well.
Plenty of requests never get a cached copy. Logged-in users, WooCommerce carts and checkouts, wp-admin, REST API calls, search results and WP-Cron all go straight to PHP. On a store or a membership site, that’s the traffic that pays the bills.
So two visitors can hit the same site and meet two different servers. The one reading a cached page gets a near-instant response. The one checking out waits on PHP workers and database queries.
web.dev puts a good Time to First Byte at 0.8 seconds or less and calls anything over 1.8 seconds poor. Test TTFB on an uncached URL, like the cart page, and you’re measuring the real server instead of the cache.
Four Server Signals Worth an Alert
An uptime check tells you a site is down. These four tell you it’s about to be.
- Memory and swap. When RAM runs out, Linux swaps to disk and PHP slows to a crawl long before anything crashes. Alert on swap use, not only on free memory.
- PHP-FPM workers. Every uncached request needs a free worker. When the pool hits its pm.max_children limit, requests queue, and the PHP-FPM log says so in plain words.
- Slow database queries. MySQL’s slow query log names the exact query and how long it took. One heavy plugin query on a busy table can drag the whole site down.
- Disk space. Backups, logs and cache files all grow. A full disk stops MySQL from writing, and the site goes with it. The cache directory itself is a usual suspect.
None of these need a paid tool to watch. They need something checking them every minute, not whenever a client emails to say the shop feels slow.
Updates Belong on the Same Dashboard
Patchstack’s State of WordPress Security in 2026 counted 11,334 new vulnerabilities in the WordPress ecosystem during 2025, up 42% on 2024. 91% of them sat in plugins. That’s a steady stream of updates, and every one is a change to a running server.
A plugin update can add a heavier query, a new cron job or a memory spike. If server metrics live in one tool and the update log in another, nobody connects the two. Put them side by side and the cause shows up on the graph: memory climbs at 14:05, the plugin updated at 14:03.
One habit pays off here. Purge and re-warm the cache after every batch of updates, then check uncached TTFB again. A cache full of pages built before the update can hide a broken release for hours.
Borrow the Playbook MSPs Use for Fleets
Managed service providers solved this problem years ago, for a different kind of fleet. They look after client laptops and servers by the hundred, and logging into each one isn’t an option. So they run remote monitoring and management (RMM) software: an agent on every machine reports health to one console, alerts fire on thresholds, and patches roll out on a schedule.
The model maps neatly onto a WordPress care plan. One view of every client server. Alerts that route to whoever is on call. Scripted fixes, like restarting PHP-FPM or clearing a full log partition, that run without anyone opening an SSH session.
Agencies that already support client devices, the office laptops and the email, get the most from this, since one agent covers the web server and the front desk. Comparing RMM tools side by side shows which ones handle Linux web servers well and which are built mainly around Windows desktops.
A Free Stack for One Server or Fifty
Not every agency needs an RMM on day one. Open-source monitoring covers the four signals above with no license fee.
For a single VPS, Netdata installs with one command and shows per-second metrics, with collectors for PHP-FPM and MySQL ready to switch on. It’s the quickest way to see what the server does when the cache isn’t helping.
For a portfolio, the common pattern is Prometheus with node_exporter on each server, Alertmanager for routing and Grafana for dashboards. It’s free and it scales. It also takes engineering time: PromQL has a learning curve, and Prometheus keeps around 15 days of data by default.
The trade-offs of Prometheus monitoring across many clients, from its single-tenant design to its retention limits, are worth reading before you commit a weekend to it.
The choice comes down to people more than software. One server and a curious developer: Netdata. Ten servers and someone who enjoys writing queries: Prometheus. Client devices in the mix as well: an RMM.
A Weekly Check That Catches Slow Problems
Alerts handle the emergencies. A short weekly review catches the problems that creep:
- Compare uncached TTFB on the cart or a logged-in page against last week.
- Check peak memory, swap, and whether PHP-FPM hit its worker limit.
- Read the top five entries in the slow query log.
- Check disk growth and prune old backups and logs.
- Match any spike to that week’s plugin updates.
Keep the Cache, Watch the Server
A cache plugin is the cheapest speed win in WordPress, and it should stay. It decides how fast pages load. Monitoring tells you whether the server underneath can keep up when the cache steps aside. Set up the four alerts first, then pick the tool that fits the size of your fleet.
