WordPress Log Monitoring: See What Your Site Actually Does

WordPress logs almost nothing by default — and that's the problem

WordPress runs millions of sites and powers an enormous slice of the public web, but its built-in logging is essentially nonexistent. With WP_DEBUG_LOG turned on, PHP errors get appended to /wp-content/debug.log. That is the entirety of WordPress's native log story. There is no audit log of who logged in, no record of which cron hooks fired, no trace of which emails were dispatched, no notice that a plugin was activated or that a configuration option was changed.

In a small personal blog this is fine. In production — where the site is part of a business, where downtime costs money, where compliance asks "who changed this and when" — it is a void. The site keeps running, the visitors keep arriving, but you have no record of what the application is actually doing under the hood. WordPress log monitoring is the practice of closing that gap: capturing structured events from inside the application, deriving metrics from them, and surfacing the patterns that matter.

This guide covers what WordPress logs by default, why debug.log is not monitoring, what proper WordPress log monitoring actually captures, how to set up logging that you can act on, and what the difference looks like in practice on a real production site.

Why WordPress logging is so thin out of the box

There are historical reasons. WordPress was designed in 2003 to run on shared hosting with whatever PHP version the host happened to have. Adding heavy logging would have meant disk usage that small hosts couldn't accommodate, configuration complexity that beginner users couldn't manage, and database overhead that the typical LAMP stack of the era couldn't take. So core stayed quiet.

The result is an application that, twenty years later, still treats logging as someone else's problem. The plugin ecosystem has filled in pieces — security plugins log auth events, contact-form plugins log submissions, e-commerce plugins log orders — but each captures its own slice in its own format, none coordinate, and none provide a coherent picture of what the site is doing.

Common misconceptions that keep teams blind

• "My uptime monitor tells me if the site is down." An uptime monitor returns a 200 if the homepage renders. It does not know whether scheduled posts are publishing, whether wp_mail is delivering, or whether bots are flooding wp-login. Uptime vs health is a real distinction.
• "My security plugin logs the bad stuff." Security plugins log what they decided to act on. Everything they let through — which is most of the traffic — leaves no audit trail. You see the blocks, not the misses.
• "My host has logs." Host-level logs are access logs and error logs at the web-server tier. They do not see inside PHP. They cannot tell you that wp_mail returned false or that a cron hook silently failed.
• "WP_DEBUG_LOG is enough." debug.log captures PHP notices, warnings, and fatals. That is one signal type among dozens. It tells you when something errored. It does not tell you what your site is doing in normal operation.

debug.log is a debugging tool, not a monitoring system

The two have different goals. Debugging answers "why did this break?" — you read the trace, you find the line, you fix it. Monitoring answers "is it broken right now, and is the trend getting worse?" — you watch a number over time and react when it crosses a threshold. They are complementary, not interchangeable.

How to do basic WordPress log monitoring yourself

If you do not yet have a log-monitoring system, here is how to extract meaningful signal from what WordPress already gives you. None of this scales past one site, but it works in a pinch.

1. Enable proper PHP error logging

In wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
define('SCRIPT_DEBUG', false);

Errors now go to /wp-content/debug.log instead of being shown to users.

2. Watch the log live during incidents

If you have shell access:

tail -f wp-content/debug.log | grep -E "Fatal|Error|Warning"

This is incident-mode triage. It will not tell you anything useful between incidents.

3. Inspect cron state via WP-CLI

wp cron event list
wp cron event list --due-now
wp cron test

Look for events whose Next Run timestamp is in the past — they should have fired and didn't. Useful for one-off checks, not continuous monitoring.

4. Watch wp_options for runaway transients

A symptom of failed cron is the options table ballooning with stale transients:

wp option get cron --format=json | jq '.|length'
wp transient delete --all
SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '_transient_%';

5. Use a third-party log shipper

If you are technical and willing to roll your own, ship debug.log and access logs to ELK, Loki, or a hosted log service. You will get full-text search but you still won't have structured signals — the events come in as text and you have to parse them every time you want to extract a metric.

What proper WordPress log monitoring captures

A log-monitoring system worth running observes the application from the inside — hooking into core, plugin, and theme events as they happen, and emitting a structured record for each. Every record is a JSON object with a known schema. That structure is what makes everything downstream possible: metrics, alerts, dashboards, drilldowns.

From those raw signals, the monitoring layer derives metrics — counts, rates, percentiles, ratios — that you can chart, alert on, and compare across time. cron_executions_per_hour. wp_mail_failure_rate. login_failures_per_endpoint. php_fatal_count. Each of those is a number that tells a story when you watch it.

How to set up WordPress log monitoring that you'll actually use

Three options, ordered from least to most useful.

Option 1: Activity log plugins

Plugins like WP Activity Log capture admin actions and store them in the WordPress database. Useful for audit trails. Limitations: stored in the same database the site is using (impacts performance), only covers user-initiated actions, no metrics, no alerts beyond email-on-event, no cross-site view, no integration with the rest of the application surface.

Option 2: Roll-your-own with ELK or Loki

Run an Elasticsearch / Logstash / Kibana or Grafana Loki cluster, ship debug.log + access logs from each site, write parsing rules. Gives you full-text search across logs. Drawbacks: significant operational overhead, cost grows with log volume, signals are still unstructured (text logs), no out-of-the-box detection rules for WordPress-specific patterns.

Option 3: Domain-specific log monitoring

Install a plugin that emits structured signals for WordPress events and ships them to a service that already knows how to interpret them. You skip the parsing step, you skip the rule-writing step, and you skip the infrastructure step. This is what Logystera does — see the next section.

How Logystera does WordPress log monitoring

The Logystera WordPress plugin hooks into the core event system at thirty-plus well-defined points. Every cron tick, every wp_mail call, every login attempt, every PHP fatal, every plugin activation — captured as a structured JSON envelope, buffered locally with under 5ms overhead per request, and shipped asynchronously to the Logystera ingest gateway.

From there, the processor (Logystera's detection engine) derives metrics from the signal stream and evaluates pre-built rules against them. You get a dashboard for each site showing what is actually happening — with drill-down to the raw events when you need to understand why a number moved.

Custom dashboards and ad-hoc log search are on the roadmap, but the default panels already cover the operational questions teams actually ask: is cron running, is mail flowing, are we under attack, is admin healthy.

Real example: agency managing 40+ sites

Related guides

Frequently asked questions