WordPress Monitoring, Honestly: What to Watch and What to Skip

WordPress Monitoring, Honestly: What to Watch and What to Skip

A small bakery in Lisbon ran its entire ordering pipeline through the contact form on its WordPress site. The form had been broken for two weeks before anyone noticed. A plugin update had silently changed a hook name; the form still rendered, the submit button still animated, the "thank you" page still showed up. The emails just weren't being sent. Two weeks of orders went straight into the void.

That's the actual failure mode of an unmonitored WordPress site. Not a dramatic outage. Not a hacker on a magazine cover. A quiet, embarrassing, two-week stretch where the site looked fine to a glance and was costing money the entire time.

This is a guide to catching that kind of problem. It's scoped strictly to what Netwarden's WordPress plugin and agent actually monitor, and just as importantly, what they don't. There's a lot of fluff in this category — guides that promise to track Core Web Vitals from multiple continents and run synthetic user-journey tests with browser automation. We don't do those things. We're going to be honest about it.

If you run a WordPress site, manage a few client sites as a freelancer, or run a small WP-focused agency, this is for you. Enterprise WP teams will want a different stack. That's fine. We're not for them.

Why WordPress is different from "websites in general"

WordPress is a platform with personality. It breaks in WordPress-specific ways. A general-purpose uptime monitor will catch maybe half of those.

The things that go wrong on a WordPress site are usually one of these:

• A plugin updated and broke something. Auto-updates are the convenience trap of the decade. They keep you secure and patched, and once or twice a year they brick a feature you depend on.
• PHP-FPM died and didn't come back. Memory pressure, runaway plugin, unlucky timing during a deploy. Site goes down for the duration.
• The database is overloaded. WP-Cron firing too often, a search query without an index, a plugin scanning the whole posts table for some reason.
• Disk filled up. Backups, error logs, an uploads folder nobody's pruned in five years.
• Brute-force login attempts. Not "sophisticated attack," just bots banging on wp-login.php until they cause CPU pain or get lucky with an old admin password.
• Core or plugin out of date with a security flag. Less urgent than the above but still worth knowing about before you read about it on Hacker News.

A vanilla uptime check ("did the homepage return 200?") catches almost none of those. Some of them, the homepage will return 200 the entire time. The bakery's contact form did.

So WordPress monitoring needs to look inside the application, not just at it from the outside.

What Netwarden actually monitors on a WordPress site

We have two pieces working together: the Go agent (running on the host, monitoring the system) and the WordPress plugin (running inside WP, monitoring the application). They report to the same Netwarden account and the same dashboard.

Here's what each piece covers, in plain language.

From the agent (the host side)

The agent runs as a systemd service on Linux (or its Windows/macOS equivalent), installed via curl -sSL get.netwarden.com | bash. It watches everything outside WordPress itself:

• Host uptime, CPU, memory, disk, swap. Standard host vitals. Useful mostly for catching the host going down or running out of disk.
• Response time and HTTP status of the site URL. This is your "is it actually serving pages" check. The agent can hit your URL on a schedule and report back.
• MySQL or MariaDB health. Auto-discovered when present. Reports queries per second, active connections, slow query count, replication lag if applicable. This is how you catch the "the database is dragging" problem before users do.
• Service health for PHP-FPM, nginx/Apache, and the database server. Whether the process is running, restarting, or dead.
• Disk space alerts. The slow killer of WordPress sites. Backups pile up. Logs pile up. Then nothing can write.

From the WordPress plugin (the application side)

The plugin installs into a WP site like any other plugin. It calls home to your Netwarden account. It watches things only WordPress knows about:

• PHP error count. Errors and warnings logged by WordPress and PHP. A spike here is almost always a plugin or theme misbehaving.
• Plugin and theme update availability. The plugin distinguishes between security updates and general updates so you can prioritize.
• WordPress core version drift. Are you running the latest stable? Behind by how many releases?
• Failed login attempts. Aggregate count over time, with spike detection. Useful for catching brute-force attempts without being a full WAF.
• Site health basics. Whether wp-cron is firing, whether WordPress thinks something is wrong with itself.

That's the surface area. It's deliberately not huge. We'd rather do these well than do twenty things badly.

What Netwarden does not monitor (and we'd rather you know)

Here's the honest part most monitoring marketing pages skip.

• Core Web Vitals (LCP, CLS, INP). We don't measure these. If you need them, Google Search Console gives them to you for free, and PageSpeed Insights runs them on demand. We're not going to fake-ship a feature to check a marketing box.
• Real-user monitoring (RUM). We don't inject a JavaScript snippet into your pages to measure what real visitors see. That's a different product category.
• Synthetic browser tests from multiple geographic regions. We don't have a fleet of browser nodes around the world running scripted user journeys against your site. If you need that — say, for a high-traffic checkout flow — you want a tool built for that specifically.
• Page-speed score over time. We don't track Lighthouse scores. Again: PageSpeed Insights does this for free, and it's not what we're for.
• User journey testing. We don't load your site in a headless browser, click through a defined checkout path, and alert when it breaks. This is what would have caught the bakery's contact form, and we'll be honest: we don't catch that case directly. You'd catch it indirectly by watching PHP errors (the broken hook should log something) and by manually testing the form during normal updates.

If your reality involves serious user-journey monitoring, multiple-geo synthetics, or RUM, you'll want to layer something else on top of (or instead of) Netwarden. We're for the layer that handles uptime, response time, app-level health signals, host vitals, and database health — at a price that makes sense for sites measured in hundreds of dollars per month, not millions.

What to monitor first: the practical priority list

You don't need to set up everything at once. There's a useful priority order, and it maps neatly to "stuff that breaks most often" rather than "stuff that sounds impressive."

Tier 1 (set this up day one):

1. Uptime / response time of the site URL. Page-me-now alert if the site is down for two minutes or response time is over 5 seconds for five minutes.
2. Host availability. The agent reports continuously; if it stops, the host is gone or the agent crashed. Either way you want to know.
3. PHP-FPM service status. This is the one that dies and doesn't always come back. Alert if it's down for more than a minute.

Tier 2 (set up in week two):

4. Disk space. A daily-summary alert at 80%, a tell-me-today alert at 90%. Disk-full kills WordPress in unique and creative ways.
5. MySQL health. If the agent has discovered your database server, set a threshold on slow queries per minute or active connections, depending on what your normal looks like. Watch for a week before setting the threshold.
6. PHP error count. From the WP plugin. Set a threshold based on your baseline — most WP sites idle near zero, so any sustained nonzero rate is interesting.

Tier 3 (the daily-digest stuff):

7. Plugin / core security updates available. Daily email is fine. You don't need to be paged at 2 AM that an update exists.
8. Failed login attempts. Daily summary unless you see a spike (the plugin handles spike detection).
9. WordPress core version drift. Weekly summary at most.

This list is roughly in order of "what catches the most actual outages per setup hour." If you only do Tier 1, you've already covered 80% of the useful surface. Tier 2 gets you to maybe 95%. Tier 3 is hygiene.

Plugin install steps (3 minutes, give or take)

Quick version. Full walkthrough is in the docs; this is the elevator-pitch length.

1. Sign up at netwarden.com. Free tier covers one site, which is enough to evaluate.
2. Install the agent on the host that runs WordPress: curl -sSL get.netwarden.com | bash. The script handles your distro and registers the host. The agent should auto-discover MySQL/MariaDB and the web server.
3. Install the WordPress plugin. Download from the dashboard (under "Add a host" → "WordPress site"), or upload the zip via WP Admin → Plugins → Add New → Upload. Activate it.
4. Connect the plugin to your Netwarden account. The plugin settings page asks for an API key, which you copy from your dashboard. Paste, save.
5. Confirm everything reports. Within a couple of minutes you should see your host, the WP plugin's data (PHP error count, update count, login attempts), and any auto-discovered services.

That's the setup. Alerts come next, and that's where the alerts guide takes over — it's a separate post because doing it right matters more than it sounds.

Some scenarios this catches

To make this concrete, here are real-feeling scenarios and which signal would catch each one. These aren't case studies with named clients — they're the patterns we actually see.

The plugin auto-update brick. Plugin updates at 4 AM, breaks something. The site might still load, or it might 500 on every request. Caught by: response time spike or HTTP error rate (from agent), PHP error count spike (from plugin).

The runaway plugin maxing the database. A plugin starts running a heavy query in a loop. MySQL connection count climbs, slow queries pile up. Site gets sluggish. Caught by: MySQL connections / slow queries metric (agent's MySQL collector), response time spike (agent's URL check).

The brute-force login hammer. Bot gets persistent on wp-login.php. Failed login count spikes from ~zero to hundreds per minute. Caught by: failed login attempt spike detection (WP plugin).

The silent disk filler. Backups pile up, nobody noticed for six months, suddenly the disk is full and PHP can't write session data. Caught early by: disk usage threshold at 80%/90% (agent). Caught late by: site actually breaking (response time alert).

The "WordPress is on 6.4, current is 6.7" drift. Caught by: WP core version monitoring (plugin), surfaced as a daily/weekly summary, not a page.

The hacked-update scenario. A compromised plugin pushes a malicious update. The site might keep working or might break loudly. We'd catch the loud version through PHP errors / response time. The quiet version (a backdoor inserted, no visible behavior change) is genuinely outside our scope — that's a security audit problem, not a monitoring problem.

It's worth being clear about that last one. Monitoring is for things going wrong in detectable ways. Active malware that's deliberately quiet needs different tools.

Pricing reality for WP site owners

Free tier is one host with full agent + plugin functionality. That's enough to monitor a single WordPress site end to end. For a hobby blog or your own freelance portfolio, the free tier is the answer.

Solo is $9.90/month for five hosts. That's roughly the right size for a serious solo freelancer with a handful of client sites. Pro is $29.90/month for twenty-five hosts and adds white-label, which matters if you're presenting the dashboard to clients.

There are no per-check or per-metric fees. The tier you're on is a host-count limit. A WordPress site = one host, regardless of how much we're collecting from it.

Compare that to the alternatives in the WP monitoring space and the math gets straightforward: ManageWP and similar are priced per-site too, but typically more for the same surface area, and they're more focused on management (updates, backups, deploys) than monitoring. Datadog and New Relic and the enterprise crowd are built for a different planet — useful, but priced for SaaS companies, not for a freelancer running a dozen client sites on a thin retainer.

The uncomfortable bit: you still have to look at it

A monitoring system that nobody opens is just expensive log retention.

Set up the alerts in Tier 1. Pin the dashboard. Once a week, look at the site's metrics over the last seven days, even when nothing has alerted. That's how you spot the slow trends — disk creeping up, response time slowly drifting, error count gradually climbing — before they become alerts.

This is true for any monitoring tool. It's especially true for WordPress, because most WordPress problems start as gradual and become acute. The graceful failure mode is the slow drift; the abrupt failure mode is much rarer.

Fifteen minutes a week is enough. You'll be the first WordPress site owner you know who actually catches issues before clients call.

Get started

If you're convinced, the next step is small. Install the agent on whatever host runs your WordPress site, install the plugin, and watch it for a week before configuring any alerts. Get a feel for what your baseline looks like — what's "normal" PHP error count for your stack, what's a normal response time, how busy your database is during the day.

Then come back and configure alerts using the priority list above. Start with Tier 1 only. Add Tier 2 when something in Tier 1 has been quiet for a week. Add Tier 3 when you have a routine for reviewing daily summaries.

That's the cornerstone of WordPress monitoring done seriously without being expensive. The tools handle the data collection. You handle the design discipline. Together, they catch the bakery-contact-form problem before it eats two weeks of orders.

---

Keep Reading

• WordPress Uptime Monitoring on a Budget: A Freelancer's Buyer's Guide — Honest comparison of monitoring options for freelancers managing 5-15 client WordPress sites.
• Monitor 50 Client WordPress Sites Under $30/Month — How agencies handle WP monitoring at fleet scale without enterprise pricing.
• Alerts That Actually Page You — How to design the alerts mentioned in this post so they don't cry wolf.
• Getting Started with Netwarden — Install the agent, install the plugin, connect everything in under five minutes.

Ready to monitor your WordPress site? Start free with Netwarden — one site free forever, $9.90/month for five, $29.90/month for twenty-five with white-label.