WordPress Monitoring: How to See What Your Site Actually Does
Log-based monitoring for production WordPress. Cron gaps, email delivery, PHP errors, brute-force attempts, admin performance, WooCommerce — everything an uptime monitor cannot tell you.
WordPress runs roughly 40% of the web and sits at the core of most marketing stacks, membership sites, and content pipelines. Yet operationally it is a black box. Cron runs (or doesn’t) inside PHP. Emails leave your server and disappear into SMTP. Plugin updates happen in production. Error handlers swallow PHP fatals. A site can be broken for weeks while uptime monitors report 100%. By the time someone notices, the damage is done: 422 days of silently failed cron, 23 days of lost contact form leads, 340 missed orders in 11 days on an otherwise “up” WooCommerce store.
WordPress monitoring, done properly, is not a ping to the homepage every 60 seconds. It is a continuous, structured read of the logs the platform already produces — wp_mail calls, cron events, REST requests, login attempts, PHP errors, queue activity, admin actions — turned into metrics and alert rules tuned for the things WordPress actually breaks on. This page is the hub for that approach: what log-based monitoring captures, what a well-instrumented site looks like, and a set of deep-dive guides for every common WordPress failure mode.
What breaks on production WordPress
Every item below is a real failure mode we have pulled out of production logs. Each one is silent by default — the site returns 200, the uptime monitor is green, the admin notice is absent. Each has a dedicated deep-dive guide.
Cron stops running
DISABLE_WP_CRON left on after a migration, a replacement system cron never added, or a plugin captures the schedule and dies. Scheduled posts stay in draft. Transients pile up. Backups skip. The site looks normal.
Emails stop sending
SMTP credentials expire, a transactional-email plugin mis-configures after an update, DNS rate-limits deliveries. Contact forms submit, WooCommerce orders confirm in the UI, but no mail leaves. You find out when a customer calls.
wp_mail() returns false
Subtler than outright failure: wp_mail returns false for a subset of recipients, error paths in plugin code swallow it, wp_mail_failed actions fire to nobody. The “email is broken” problem with a stack trace.
Silent PHP errors
WP_DEBUG is off on production, display_errors is off, error_log points at /dev/null, or errors are caught and discarded by a theme try/catch. The site works — except for the broken feature nobody has clicked in six weeks.
wp-admin gets slow
A bloated options table, a plugin polling the dashboard on every heartbeat, an uncached WP_Query that grew with the content. Editors notice; no alert fires because the frontend is fine.
Brute force against login
501 failed logins in 30 minutes against wp-login.php, distributed across a dozen IPs. The usual security plugin blocks some and misses xmlrpc.php entirely. Without auth-signal monitoring you only see it when an account is compromised.
What log-based monitoring captures
Logs already describe everything WordPress does. The job of monitoring is to convert that stream into metrics and rules. These are the signal categories a log-first monitor produces:
| Signal category | What it tells you |
|---|---|
| Cron activity | Scheduled hook executions, runtime, failure rate, time since last run. Detects DISABLE_WP_CRON, stuck schedules, overrunning hooks. |
| Email delivery | Every wp_mail() call, recipient counts, success/failure ratio, wp_mail_failed payloads. Catches SMTP breakage within minutes. |
| Authentication | Login attempts, failed passwords, lockouts, xmlrpc.php hits, REST login events. Brute force and credential stuffing detection. |
| PHP errors | Notices, warnings, fatals, deprecations, shutdown errors, uncaught exceptions. With file, line, and stack trace attached. |
| Performance | Request latency split by route (frontend, admin, REST, cron, login). Memory peaks. Slow hooks and filters. Cache hit ratio. |
| Configuration drift | Plugin activate/deactivate, theme switch, option updates on sensitive keys, user role changes, file-edit-in-admin attempts. |
| REST & XML-RPC traffic | Request volume by namespace, 4xx/5xx by endpoint, unauthenticated-vs-authenticated split. Used for abuse detection and API health. |
| Commerce events | Checkout attempts, order status transitions, payment gateway errors. On WooCommerce, the single most useful signal set a merchant can have. |
These categories are produced from the same log stream. No separate agent per category, no cardinality blow-up, no custom metric writing. See log-based monitoring: the general approach for the underlying architecture.
How Logystera monitors WordPress
Logystera ships a lightweight WordPress plugin that hooks into the events listed above, batches them, signs the batch with an HMAC secret, and ships it to the Logystera gateway. From there the processor derives metrics, evaluates pre-built alert rules, and renders dashboards. There are no rules for you to write, no agent to install on the server, and no log pipeline to maintain — the plugin emits structured events, Logystera does the rest.
Dashboards are pre-built for WordPress operators: health signals (errors, failed logins, email delivery), performance (memory, cache, hooks, routes), admin vs frontend breakdowns, and brute-force-attack views. Rules fire on the failures uptime monitors miss: cron gaps, wp_mail_failed spikes, PHP fatal clusters, authentication storms. See the WordPress integration page for the full feature list, setup steps, and screenshots.
WordPress monitoring checklist
What a well-monitored WordPress site should detect. These are operational best practices, not a product feature list. If your current monitoring doesn’t cover these, you have blind spots.
-
1
Alert when WP cron has not run in the last 15 minutes. The most common silent failure on WordPress. Detects DISABLE_WP_CRON, dead replacement system crons, and stuck schedules.
-
2
Alert when wp_mail failure rate exceeds 5 events in 10 minutes. Covers SMTP outages, expired credentials, DNS rate-limiting, and plugin misconfiguration after updates.
-
3
Alert on PHP fatal or uncaught exception clusters. Not one-offs — repeated fatals on the same file/line within an hour. Indicates a real regression, not a transient hiccup.
-
4
Alert on brute-force login patterns. More than 100 failed logins in 10 minutes, or more than 30 failures against a single username. Include xmlrpc.php hits — most security plugins don’t.
-
5
Alert when wp-admin p95 latency doubles its 7-day baseline. Catches bloated options tables, slow plugins on dashboard heartbeat, and runaway WP_Query regressions.
-
6
Alert on plugin activation, deactivation, or theme switch in production. Change-detection signal. Someone installed something — make sure it was intentional.
-
7
Alert on REST 5xx rate spikes. API consumers, headless frontends, and JetPack-backed features all depend on REST. A spike precedes visible breakage.
-
8
Alert when an order transitions to failed or payment_error on WooCommerce. If you sell on WordPress, this is the monitor that matters most and the one least often configured.
-
9
Alert on user role escalation to administrator. Privilege changes are rare and load-bearing. Every admin promotion should be reviewed, not just logged.
-
10
Track cache hit ratio and alert below 70%. Cache going cold is a leading indicator for DB load, plugin conflict, or a forgotten cache-flush loop.
When uptime monitoring is not enough
Uptime checks answer one question: does the homepage return 200? That question is almost never the question you actually have. A site that returns 200 can still have cron dead for a year, wp_mail returning false for a week, admin at 14 seconds per page load, and 501 failed logins in a window. Every one of those is an operational outage in the only sense that matters — users and the business are affected — and none of them move a 99.9% uptime number.
Log-based monitoring asks the opposite question: is the site doing what it is supposed to be doing? That question requires structured events, not HTTP pings. For the full argument, read uptime vs. health: why 99.9% uptime means nothing →.
Further reading: WordPress monitoring guides
Every failure mode above has a dedicated guide covering detection, root cause, and fixes — written from real production logs.
WP cron not running: detection & fixes
The single most common silent failure on production WordPress. How to detect it and how to keep it detected.
WordPress emails not sending
SMTP breakage, expired credentials, DNS rate-limits, plugin misconfiguration. Detection inside 10 minutes.
wp_mail() not working
Root causes, what wp_mail_failed actually contains, and how to wire the signal to an alert.
Silent PHP errors
How errors hide on production, which handlers eat them, and how to surface them without flooding.
Slow wp-admin
The five common causes of a slow dashboard and how to find the guilty plugin or query from request logs.
Brute-force attack detection
wp-login.php, xmlrpc.php, and REST login attempts. Patterns, thresholds, and why security plugins miss half of it.
WordPress log monitoring
What the logs already tell you, what gets lost by default, and how to turn it into operational visibility.
Uptime vs. health
Why 99.9% uptime means nothing if the site returns 200 while cron is dead and email is broken.
Log-based monitoring: the general approach
The architectural pattern: derive metrics from structured log events, apply rules, alert on intent — applied across WordPress, Drupal, and Vault.
