debug.log
debug.log is the file where WordPress records PHP errors, warnings and notices while its debug log is switched on. It is the first place to look when a page is blank or shows a critical error, and by default anyone who knows its address can read it.
- By
- WP Ministry
- Published
In short
- The log is written only while WP_
DEBUG and WP_ DEBUG_ LOG are both true in wp-config.php. Both are off by default. - Read from the bottom. The newest lines are last, and a line that says "PHP Fatal error" is one that stopped a page.
- In wp-content the log has a web address that anyone can open. Move it or close it, and delete it when you have finished.
debug.log is a plain text file in which WordPress records what PHP reports while a site runs: errors, warnings and notices, one to a line, each with the time, the file and the line number. It is written only while two settings in wp-config.php, WP_ and WP_, are both true. Both are off by default, so most sites have no such file.
It matters because WordPress keeps errors away from visitors. A page that fails shows a blank screen, or "There has been a critical error on this website.", and no cause. The log holds the cause.
Where you meet it
The file is wp-content/. If WP_ is given a file path in place of true, the log is that file.
A line looks like this:
[08-Oct-2026 02:52:21 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 1052672 bytes) in /var/www/html/wp-content/plugins/example/example.php on line 3New lines are added at the bottom. The word after "PHP" says how serious the line is. A fatal error halts the page. A warning or a notice does not, and a deprecation notice is about code that will stop working in a future version.
How to turn on WordPress debug mode has the lines that switch the log on and off. To have the lines explained, paste them into the error message and debug.log decoder, which reads them in your browser.
What goes wrong
- Anyone can read it.
wp-contentis part of the website, so the log has an address:https://. WordPress's documentation calls error logs in publicly accessible places a security risk. It says a log should ideally sit above the site's public folder and, failing that, be given a permission of 600 and be closed to web requests. While the log is on, Site Health reports "Your site is set to log errors to a potentially public file".example.com/ wp-content/ debug.log - It is left on. WordPress's documentation says its debug tools are meant for local and staging sites, not live ones. Switching the log off stops new lines. It does not remove the file, which stays readable at its address until you delete it.
- No file appears. The file is made when there is a first line to write. If nothing arrives,
WP_is stillDEBUG false, the lines sit below the stop-editing line, or the web server is not allowed to write inwp-content. - It is full of lines that have nothing to do with the fault. With debug mode on, WordPress has PHP report every warning and notice, including many for things that are not broken. Look for the fatal error recorded at the moment the page failed. How to fix a critical error and how to fix the white screen of death both start from that line.
How to look at yours
Go to Tools, then Site Health, open the Info tab and expand WordPress Constants. The rows WP_ and WP_ read "Enabled" or "Disabled". If the log has been given a path, the WP_ row shows the path.
Common questions
Is it safe to delete debug.log?
Yes. It is a record, and nothing on the site reads it. If the log is still switched on, WordPress makes a new file the next time it has a line to write.
Why does my site have a debug.log when I never turned it on?
At some point both settings were switched on in wp-config.php, and they may still be. Open that file and look. If nobody is investigating a fault, set WP_ to false and delete the log.
How is debug.log different from the server's error log?
debug.log belongs to WordPress and exists only while its debug log is on. The server keeps logs of its own, set in PHP's and the web server's configuration. Your host can tell you where they are. When a fault stops WordPress before it loads, such as a mistake in wp-config.php or a bad line in .htaccess, only the server's log records it.