WordPress Debug Log: How to Turn It On and What to Do With What You Find

Most WordPress site owners have heard that there is a debug log somewhere. Almost none of them have it turned on. The ones who do turn it on, open it, see a wall of text, and close it.

This is a waste of the most useful diagnostic tool you have.

The WordPress debug log is a record of everything your site tried to do and could not do cleanly. PHP errors, warnings, notices, failed database operations, plugin exceptions. When your site breaks in a way that leaves no visible trace on the front end, the debug log is usually where the evidence is sitting, waiting to be read.

Here is how to turn it on, what to look for, and how to act on what you find.

Turning it on

Open your wp-config.php file. It lives in the root of your WordPress installation. You are looking for this line:

define( 'WP_DEBUG', false );

Change it to these three lines:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG turns on error reporting. WP_DEBUG_LOG writes those errors to a file instead of showing them on screen. WP_DEBUG_DISPLAY set to false keeps errors out of your visible pages. You want all three.

The log file is created at /wp-content/debug.log. You can access it via FTP, your hosting file manager, or SSH. If the file does not exist yet, WordPress creates it the first time an error occurs.

One note: on some managed WordPress hosts, wp-config.php is read-only or managed by the host. If you cannot edit it directly, your host’s control panel may have a debug mode toggle that does the same thing.

What the log actually contains

Open the file. Each entry looks roughly like this:

[21-May-2026 03:14:22 UTC] PHP Warning: Undefined variable $order_id in /wp-content/plugins/my-plugin/includes/functions.php on line 142

Four pieces of information in every entry: the timestamp, the error type, the message, and the file and line number where it happened.

Error types, in order of severity

PHP Fatal Error is the most serious. This is a failure that stopped execution entirely. If you have a blank white screen, a 500 error, or a function that simply does nothing, a fatal error is the first thing to look for. The log will tell you exactly which file and line number caused it.

PHP Warning means something unexpected happened but execution continued. Warnings are often ignored because the site appears to work. They should not be ignored. A warning frequently signals a condition that will become a fatal error under slightly different circumstances, or is silently corrupting data.

PHP Notice is the least severe. WordPress and its plugins generate a lot of notices. If you have a large, busy site, the log may be full of them. For diagnostic purposes, look at notices from your own plugins and theme files, and treat notices from core WordPress files as lower priority.

Deprecated means a plugin or theme is using a function that WordPress has flagged for removal in a future version. Not urgent, but worth addressing before the next major WordPress update.

Reading a specific failure

You have a failure: a form did not submit, a product did not save, a webhook did not fire. Here is how to use the log to find it.

Note the exact time the failure occurred. Open the log and look at the entries from that time window. You are not reading the entire log. You are looking at a narrow time slice.

Look for fatal errors first. If one exists at or just before the failure time, that is almost certainly your cause. Copy the complete error line, including the file path and line number.

If there are no fatals, look at warnings from the time of the failure. A warning involving a WooCommerce function, a form plugin, or your theme’s checkout template is a signal worth investigating even if it does not look fatal.

If the log is clean at the time of the failure, the failure is happening silently. This means the function that should have run either did not run at all, or ran and produced no output and no error. This is the harder case, and it is where you need to add temporary logging to specific code paths to find out whether they executed. If you are not sure how to do that, it is a one-sentence instruction to any AI assistant: “Add a line to this function that writes its inputs to the WordPress debug log.”

The three most common things you will find

A plugin generating fatal errors after an update. The log shows a fatal error in a specific plugin file. Deactivate that plugin. The behavior you lost will return if that plugin was the conflict. Update the plugin if an update is available. If the error persists after the update, contact the plugin developer with the exact error text.

A function being called before it is defined. This appears as “Call to undefined function” or “Class not found.” It means the plugin or code that defines the function either did not load or loaded in the wrong order. This is a plugin conflict or a plugin initialization timing issue.

A database operation failing silently. This does not always produce a log entry, but when it does it appears as a warning about a failed database query. WooCommerce in particular can fail to write order data or inventory updates with no visible front-end error. If you have a save-button-appears-to-work-but-nothing-changes problem, look for database warnings in the log from that time window.

When to keep the debug log on

The debug log has a cost: it generates disk I/O and the file grows continuously. On a production site with real traffic, you do not want WP_DEBUG permanently enabled.

The right pattern is to enable it when you are actively diagnosing a problem and disable it when you are done. If you are in a development or staging environment, keep it on all the time.

Some managed hosts offer a debug log through their dashboard that you can toggle on and off without editing wp-config.php. If yours does, use it. The easier it is to access the log, the earlier in a debugging session you will use it.

What to do with the log once you have it

If you are handing the failure off to a developer, send them the relevant section of the log along with a description of what you were doing when the failure occurred. The log is the context they need. They do not need to ask you for more information when they have the error text, the file path, and the timestamp.

If you are working with an AI assistant, paste the relevant log entries directly into your prompt. “The checkout is broken” produces a guess. The exact PHP error text and file path produces a diagnosis.

Loupely captures your WordPress debug log automatically as part of every diagnostic capture, alongside your PHP errors, browser state, and WooCommerce data. It reads the relevant entries from the time window of your failure and explains them in plain English. If you are doing this manually every time something breaks, that is worth knowing: useloupely.com