Quick answer: The WordPress debug log records PHP errors, warnings and notices to a file. Turning it on takes three lines in wp-config.php. Reading it usefully means knowing which severity levels matter, which are safe to ignore, and never leaving errors displayed on a live site.
The debug log is the closest thing WordPress has to a flight recorder. When something breaks, it usually knows why. Most site owners never turn it on — and a smaller but more worrying group turn it on and then leave it running wide open for years.
Here’s how to do it properly.
Turning it on
Three constants in wp-config.php, added above the “That’s all, stop editing” line. If WP_DEBUG is already defined further up, edit that rather than adding a second one.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Each does something distinct, and the third one is the one people get wrong:
WP_DEBUG— the master switch. Turns on error reporting.WP_DEBUG_LOG— writes those errors towp-content/debug.log.WP_DEBUG_DISPLAY— controls whether errors print into the page. On a live site this must be false.
Leaving display on means PHP errors appear in your public HTML, complete with file paths, and sometimes database or configuration details. It’s an information disclosure issue and it looks terrible to visitors. Log it, don’t show it.
You can also send the log somewhere less guessable than the default:
define('WP_DEBUG_LOG', '/home/user/logs/wp-errors.log');Worth doing, because wp-content/debug.log is sometimes readable over the web depending on server configuration — and that file may contain paths and query fragments you’d rather not publish. If you keep the default location, confirm the file isn’t publicly accessible by trying to load it in a browser.
What the severity levels mean
Everything in the log is prefixed with a type. Knowing which ones to care about turns an intimidating wall of text into a short list of real problems.
Fatal error — fix immediately
PHP stopped executing. Something on your site is broken right now, or was at the moment this was logged. These are never safe to ignore. Common causes: a call to an undefined function, a class declared twice, an exhausted memory limit.
Warning — investigate
PHP carried on, but something wasn’t right. A file it expected wasn’t there, a function got an argument of the wrong type, a network call failed. The page probably still rendered, possibly with something missing. A warning repeating hundreds of times a day is a genuine problem wearing a quiet costume.
Notice — usually cosmetic
Sloppy but harmless code. An undefined array key, an unset variable being read. Mostly these tell you a plugin author wasn’t fastidious. Worth ignoring unless one is appearing at enormous volume, in which case the sheer write activity is costing you something.
Deprecated — your early warning system
The most useful and least appreciated category. It means a plugin or theme is using something PHP or WordPress has marked for removal. Nothing is broken today. It will break on a future update — and now you know which plugin, months before it becomes an emergency.
A spike in deprecation notices right after a WordPress or PHP upgrade is worth reading carefully. That’s a list of what’s going to fail next.
Reading a log entry
Every line follows the same shape: a timestamp, the severity, the message, and — most importantly — the file path and line number where it happened.
That path is the answer to “which plugin is doing this?”. A path containing /plugins/some-plugin-name/ tells you exactly who to blame, and whether it’s something you can fix, something to report to the author, or something to replace.
A few habits that make logs much easier to work with:
- Read from the bottom. New entries append, so the most recent — and usually most relevant — material is at the end.
- Look for repetition, not variety. One error repeated 4,000 times is one problem. Ten distinct errors appearing once each are often less urgent.
- Correlate with timestamps. If entries start abruptly on a particular date, check what was updated that day.
- Ignore the first flood. Turning debugging on for the first time surfaces years of accumulated notices at once. Don’t panic; sort by severity.
The file that eats your disk
WordPress does not rotate or cap debug.log. It appends forever.
On a site with a chatty plugin generating a notice on every page load, this file can reach hundreds of megabytes — occasionally gigabytes — and it’s a well-known way to fill a hosting account’s disk quota without ever noticing. Once the disk is full, uploads fail, backups fail, and in the worst case the database can’t write either.
So: check the file size periodically. Truncate it when it gets large — deleting the file is fine, WordPress recreates it. And if you’re leaving debugging on permanently, know what’s generating the volume.
Should you leave it on?
Reasonable people disagree. The case for leaving it on: when something breaks, you have history rather than having to reproduce the problem with logging enabled. That’s genuinely valuable, and it’s why many developers leave it running with display off.
The case against: file growth, a small performance cost, and the risk that a misconfiguration exposes the log publicly.
A sensible middle position for a production site: leave WP_DEBUG_LOG on with display firmly off, put the file outside the web root, and actually look at it occasionally. A log nobody reads is just a slowly growing file.
That last part is the sticking point, and it’s the reason Canary Site Monitor’s Pro tier parses the log for you — reading recent entries, sorting them by severity, and surfacing the ones that matter in plain English in your morning digest, rather than expecting you to open a text file over FTP on the off chance something’s wrong.
Either way, turn it on. A site with no debug log isn’t a site with no errors — it’s a site with no record of them.