WordPress Error Logs: How to Read debug.log Like an Engineer

WordPress writes errors to /wp-content/debug.log when WP_DEBUG_LOG is enabled, but the entries look like nonsense if you have never read a PHP stack trace. This guide turns each common line into a clear cause and fix.

Every WordPress engineer I know has the same first move when a site breaks: open debug.log. It is the closest thing WordPress has to a black-box recorder. The trouble is that the file reads like a foreign language until someone walks you through it.

I have spent twelve years staring at this file at odd hours, and most entries fall into a small set of patterns. Once you can recognize them, you stop guessing and start fixing. This guide is the dictionary I wish I had on my first job.

We will turn on logging the right way, then translate each common line you will see, from fatal errors that take the site down to deprecation notices you can usually ignore. By the end you will be able to read any debug.log entry and know exactly what to do next.

Turn On the WordPress Error Log Safely

WordPress does not log errors by default. You have to opt in by editing wp-config.php. The safe pattern, and the one I use on every client site, is to log to a file without showing errors to visitors. That way you get full debugging power without leaking file paths to the public.

Open wp-config.php through FTP or your host's file manager and place the snippet below right above the line that reads /* That's all, stop editing! Happy publishing. */. Order matters, these constants must load before WordPress bootstraps the rest of the request.

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

Where to Find debug.log and How to Open It

Once logging is on and the error fires again, WordPress writes to /wp-content/debug.log. Open it with any plain text editor, scroll to the bottom, and read upward. The newest entries sit at the end of the file, and the most recent fatal is almost always the one taking the site down.

Each line follows a predictable shape: a timestamp in UTC, an error level, a human message, and a file path with a line number. Once you train your eye on that shape, scanning the log becomes second nature.

[20-Jun-2026 09:14:02 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /home/site/public_html/wp-content/plugins/my-addon/loader.php:42

Dictionary: The Errors You Will Actually See

Below are the entries that account for the vast majority of real-world debug.log output. For each one I have included the literal message you will see, what it means in plain English, and the fix I run first.

• PHP Fatal error: Allowed memory size of N bytes exhausted — PHP ran out of memory mid-request. Raise WP_MEMORY_LIMIT to 256M or 512M, then look at the file path on the same line to find which plugin is the heavy spender.
• PHP Fatal error: Maximum execution time of N seconds exceeded — a request took too long, usually a cron job, an import, or a slow external API call. Increase max_execution_time on the host, or move the work to WP-CLI or Action Scheduler.
• PHP Fatal error: Uncaught Error: Call to undefined function X() — the calling code expected a function that does not exist in this PHP version or in the currently active plugins. Either restore the missing plugin or update the caller to a supported API.
• PHP Fatal error: Cannot redeclare function X() — two pieces of code defined the same function name. Rename the function you control, or deactivate one of the two conflicting plugins.
• PHP Parse error: syntax error, unexpected token — a file has a typo, usually in functions.php or wp-config.php after a manual edit. Revert the edit or fix the syntax, the site will stay down until you do.
• PHP Warning: include(...): failed to open stream — a plugin tried to load a file that is missing. Reinstall the plugin from a fresh ZIP, do not just delete the line.
• PHP Warning: Cannot modify header information - headers already sent — something printed output before WordPress sent its HTTP headers, often a stray space at the top of wp-config.php or an echo in a theme file. Remove the early output.
• PHP Notice: Undefined index / Undefined variable — a plugin read an array key or variable that was never set. Usually harmless but noisy, and a sign the plugin has not been updated for current PHP.
• PHP Deprecated: Function X is deprecated — your PHP version flagged a function the plugin should stop using. Update the plugin or report the issue upstream, then mute the noise so it does not hide real errors.
• WordPress database error … for query — MySQL rejected a query. The exact error text tells you whether it is a missing table, a syntax issue, or a permissions problem.

Trace a Real Error From debug.log to Fix

Reading is half the skill. The other half is acting on what you read. Here is the routine I run on every client log, in order, so I never waste time chasing the wrong lead.

Step one, find the newest fatal. Anything above it is older noise. Step two, copy the file path and line number into your editor or FTP client and open that exact line. Step three, identify the component, almost every path includes /wp-content/plugins/<name>/ or /wp-content/themes/<name>/, which tells you who to fix or remove.

Step four, decide between three options: update the component, swap it for an alternative, or remove it. I do not try to patch third-party plugin code on a live site unless I own the codebase. A clean swap is faster and safer than a hotfix.

Keep the Log Useful Over Time

A debug.log that grows for months becomes useless. Every real error gets buried under thousands of repeated notices. After you ship a fix, delete the log, reproduce normal traffic, and confirm the file stays small. If it grows again, you have another bug to chase.

On sites that handle sensitive data, move the log outside /wp-content with an absolute path so it cannot be downloaded by a curious visitor. And turn debug mode off entirely once you are done. Logging is a tool for fixing, not a default state for a healthy site.

define('WP_DEBUG_LOG', '/var/log/wp/site-debug.log');

1. 1Open wp-config.php and set define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true);, define('WP_DEBUG_DISPLAY', false);.
2. 2Reproduce the error on the site so a fresh entry lands in /wp-content/debug.log.
3. 3Open debug.log via FTP or your host's file manager and scroll to the most recent timestamp.
4. 4Match the error prefix (PHP Fatal error, PHP Warning, PHP Notice, PHP Deprecated) to the dictionary in this guide.
5. 5Read the file path at the end of the line to identify which plugin or theme triggered it, then fix or replace that component.