WordPress Error Log: Where to Find It and How to Read It

When WordPress shows a critical error, a white screen or a 500 error, the real reason is almost always written to a PHP error log. Finding that log turns a vague “the site is broken” into a specific file and line number.

There are two places to look: your hosting account’s error log, and WordPress’s own debug.log, which you switch on in wp-config.php.

Check your email first

When a plugin or theme causes a fatal error, WordPress sends an email to the site’s admin address with the subject “Your Site is Experiencing a Technical Issue”. It names the plugin or theme and includes the error message, plus a recovery mode link that lets you log in with the broken plugin paused. If that email arrived, you may already have your answer.

Find your host’s error log

Most hosts log PHP errors whether or not WordPress debugging is on. In your hosting control panel, look for a section called Logs, Error Logs or PHP Logs. Managed WordPress hosts usually have one on the site’s dashboard.

• cPanel: Metrics → Errors shows the most recent web server errors. On many cPanel servers, PHP also writes a file named error_log into the folder where the error happened, often the site root or wp-admin. Look for it in the file manager.
• Plesk: open the domain and go to Logs, then filter for errors.
• VPS or your own server: PHP-FPM and web server logs usually live under /var/log/. The exact path depends on the setup.

The host’s log is the only option if the error happens before WordPress loads, for example a typo in wp-config.php itself.

Turn on the WordPress debug log

If the host’s log is empty or you can’t find it, have WordPress write its own. Connect with SFTP or the file manager, open wp-config.php in the site root, and add these lines above /* That's all, stop editing! */:

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

Most wp-config.php files already contain define( 'WP_DEBUG', false );. Change that line to true rather than adding a second one, since defining the same constant twice causes a warning of its own.

Here’s what each line does:

• WP_DEBUG turns on debugging mode.
• WP_DEBUG_LOG writes errors to wp-content/debug.log.
• WP_DEBUG_DISPLAY and display_errors keep errors off the screen, so visitors don’t see them.

Now repeat whatever triggers the problem: load the broken page, save the post, run the checkout. Then open wp-content/debug.log. The newest entries are at the bottom.

If you’d rather keep the log out of the public web folder, give WP_DEBUG_LOG a full path instead of true. Use a real folder on your account that sits outside the site root:

define( 'WP_DEBUG_LOG', '/home/youraccount/logs/wp-errors.log' );

If no file appears, check that wp-content is writable by the web server, and that you edited the wp-config.php for the site you’re testing.

How to read a fatal error line

A typical fatal error looks like this:

[19-Oct-2026 14:02:11 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /home/example/public_html/wp-content/plugins/shop-sync/includes/class-sync.php:142
Stack trace:
#0 /home/example/public_html/wp-includes/class-wp-hook.php(324): Shop_Sync->run()
#1 /home/example/public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters()
...

Read it left to right:

1. Timestamp. Usually in UTC. Match it to when the site broke, and ignore older entries.
2. Severity. Fatal error stops the page and is what causes critical errors and white screens. Warning, Notice and Deprecated rarely break anything.
3. Message. What went wrong. Here, the code called a WooCommerce function that wasn’t available, which usually means WooCommerce is inactive or the add-on loaded too early.
4. File and line. The path after wp-content/plugins/ or wp-content/themes/ names the culprit. In this example it’s the plugin in the shop-sync folder, line 142.

The stack trace below the error lists the chain of calls that led there. Lines pointing into wp-includes or wp-admin are usually WordPress itself calling the plugin, not the cause. Look for the first line that points into a plugin or theme folder.

A few messages come up often:

• Allowed memory size of … bytes exhausted: PHP ran out of memory. See WordPress memory limit.
• Call to undefined function or Class not found: a plugin depends on another plugin that is missing or inactive, or two versions don’t match.
• Syntax error, unexpected …: a file has a typo, often from a code snippet pasted into functions.php. Our guide to adding code snippets safely explains how to avoid that.

Once you know the plugin or theme, deactivate it, roll it back or update it. If you can’t reach the dashboard, rename its folder in wp-content/plugins/. Our guide to handling a critical error covers the next steps.

Errors that don’t break the page

A busy log full of warnings and deprecation notices is normal, especially after a PHP upgrade. They’re worth passing to the plugin developer, but they’re rarely why a site is down. Focus on fatal errors near the time of the problem.

For errors in the admin area, the free Query Monitor plugin shows PHP errors, slow database queries and which plugin caused them, on the page you’re viewing, to logged-in administrators only.

Turn it off afterward

Don’t leave debugging on once you’ve found the problem. debug.log keeps growing, and by default it sits in a public folder where anyone who guesses the address can read your server paths and plugin details.

1. Set WP_DEBUG back to false and remove the other lines you added.
2. Delete wp-content/debug.log.
3. If you need logging on for a while, use a log path outside the site root as shown above.

On Apache servers you can also block the file in your root .htaccess:

<Files "debug.log">
    Require all denied
</Files>

Need it fixed now?

If you’ve found the error but aren’t sure what to do with it, our $79 one-time fix gets a developer on it, usually within 24 hours, and it’s fixed or your money back. Our Care Plans include monitoring that catches errors like this before your visitors do.