What Your Empty WordPress Debug Log Is Hiding

Right now, 68 percent of WordPress sites have WP_DEBUG set to false. That means PHP errors, warnings, and notices are getting swallowed without a trace. Here’s why that matters.

The silent default

WordPress ships with WP_DEBUG turned off in wp-config.php. Most hosts leave it that way. Most developers do too, because debug output on a live site breaks pages. Error messages print right above the footer. JSON endpoints return garbled responses. So the default stays off.

Off means silent. Silent means you only find out about a PHP fatal when the page goes white, or a plugin update kills your checkout flow, or your scheduled post never published and nobody knows why.

The fix is not “turn on WP_DEBUG on production.” The fix is a logging setup that captures errors without showing them to visitors.

What WP_DEBUG_LOGs gives you

Set define('WP_DEBUG_LOG', true); in wp-config.php. Errors go to /wp-content/debug.log instead of printing on screen. The file grows over time. A healthy site generates maybe 50 lines a week. A site with a bad plugin generates thousands per hour.

Most WordPress monitoring tools overlook this file. They check uptime, page speed, and database queries. They do not tail the debug log. That means plugin authors shipping deprecated function calls, mismatched return types, and undefined array keys stay invisible until something breaks.

Three common things that show up in debug.log before they show up anywhere else:

• Deprecated function calls. A plugin calls a WordPress function that was marked deprecated 3 versions ago. The site still works. The log fills with 50 warnings per page load. One core update later, the function is gone and the feature breaks.
• Undefined array keys. A plugin assumes a POST value exists and does not check isset() first. On a normal request the value is there. On a malformed request the log shows PHP Warning: Undefined array key "user_id". The user sees nothing wrong. You see the warning trail if you look.
• Class redeclaration errors. Two plugins define a class with the same name. The first one loads fine. The second one throws PHP Fatal error: Cannot redeclare class. The page goes white. The log has the exact line and file path.

Why empty logs are the real warning

An empty debug.log file is not proof that your site is healthy. It is proof that WP_DEBUG is off. Some hosts delete the log on every deploy. Some set WP_DEBUG_DISPLAY to false but forget to enable the log file. Some run PHP 8.x with strict error reporting off, so notices and warnings never surface.

Check the first line of your debug.log. If it starts with “Nothing logged yet” or does not exist, your site is running in silent mode. That means every PHP warning that happens today is invisible until it becomes a fatal error.

Three settings to fix this today

These go in wp-config.php, above the “That’s all, stop editing” line. Do not edit the theme functions.php for debug settings, they get overwritten on theme updates.

1. WP_DEBUG with log target

define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);. Enables logging, writes to /wp-content/debug.log, hides errors from visitors. This is the only safe combination for production.

2. SAVEQUERIES for SQL debugging

define('SAVEQUERIES', true);. Each database query gets logged with caller file, line number, and execution time. Add it when troubleshooting a slow admin page or a form that lags. Remove it after. The performance cost is real on production. Use it like a diagnostic tool, not a permanent setting.

3. Error log rotation

The debug.log file has no built-in size limit. On a busy site with a noisy plugin, it can grow to 500 MB in a week. Set a cron job or server task to truncate it weekly. Keep the last 30 days compressed. A tool like SitePulse can watch for new warnings and alert you, so you do not need to check the file by hand.

What to watch for in the log

Not every warning is actionable. PHP itself generates notices for minor things like accessing a variable that was not set. The signal to watch is frequency. A single deprecation notice repeated 2,000 times per hour is a plugin that needs replacement. A class redeclaration error that happens once per page load is a conflict that will escalate.

Three patterns that justify immediate action:

• The same warning appears on every page load (plugin-level issue, not request-specific)
• The warning references a function that was removed in the current PHP version
• The log contains a PHP Fatal error (site component already broken)

The staging environment gap

Developers often enable WP_DEBUG_LOG on staging but not on production. The logic is sound. But staging environments rarely match production exactly. Plugin versions drift. One site runs a caching plugin the other does not. The database is a three-month-old clone. A warning that fires in production may never fire in staging, and vice versa.

The fix is to sync staging with production weekly, including plugin versions and the database. Then enable WP_DEBUG_LOG on staging and compare the output with whatever production captures. A warning that appears only in production is still actionable.

Worth checking now

Open /wp-content/debug.log right now. If it is empty or missing, your site is flying blind. The next plugin update that introduces a PHP version incompatibility will show up as a white page, not a warning you could have fixed preemptively. Fifteen minutes of config changes today saves hours of recovery later.

If you manage multiple WordPress sites, checking each one by hand is not practical. That is where a monitoring tool like SitePulse that reads the debug log and flags new issues makes the difference between catching a warning and discovering it when a customer reports a broken page.