WordPress Error Log Location: Where to Find and Read

The two log levels: WordPress vs PHP

WordPress and PHP write different logs. The WordPress debug log records notices from WordPress, themes and plugins once you ask for it. The PHP error log records fatals and warnings from the interpreter, even when WordPress debug is off.

• wp-content/debug.log exists only after WP_DEBUG_LOG is true.
• error_log in a folder is PHP writing beside the script that failed.
• cPanel Metrics, then Errors, is the panel view of recent server errors. It does not replace debug.log.

A white screen often needs both files: the PHP log names the fatal, and debug.log names the plugin or theme call that led to it. On WebJi® WordPress hosting both sit in File Manager, and the repair order for the crash itself is on the WordPress 500 error page.

Enabling WP_DEBUG safely

Add these lines in wp-config.php above the line that says "That's all, stop editing." WP_DEBUG_DISPLAY false keeps the message out of the public HTML.

1. Set WP_DEBUG to true so WordPress reports errors.
2. Set WP_DEBUG_LOG to true so they are written to wp-content/debug.log.
3. Set WP_DEBUG_DISPLAY to false so visitors do not see the trace.
4. Reload the failing page once. The file appears on that request, not before.

Reading wp-content/debug.log

Open wp-content/debug.log in File Manager or download it. Each line has a timestamp, a level such as Notice or Fatal, the message, and the file and line that triggered it. The newest lines are at the bottom.

A plugin path in the message means that plugin. A theme path means the theme. wp-includes is core, and it is often only the place a plugin crashed into. Rename the log after you read it so the next test starts clean.

[29-Oct-2026 14:22:07 UTC] PHP Fatal error:  Uncaught TypeError:
Cannot access offset of type string on null in
/home/user/public_html/wp-content/plugins/example/includes/render.php:82

Read it left to right: the timestamp, the level, the message, then the absolute path and line number. Here the fatal came from a plugin file at line 82, so the plugin update is the suspect, not the server. Copy that whole line into a ticket when you ask for help.

cPanel's error_log files

In cPanel open Metrics, then Errors. That list is the recent PHP and Apache errors for the account. It does not require a change in wp-config.php.

File Manager may also show a file named error_log inside public_html, wp-admin, or a plugin folder. That file is local to the directory whose script failed. Delete it only after you have copied the lines you need. It will be recreated on the next error.

Finding the PHP error log location

The account-wide PHP log is not always debug.log. In cPanel open MultiPHP INI Editor or the PHP info page and look for error_log. On many cPanel accounts that path is inside the home directory, not inside WordPress.

If log_errors is off, PHP writes nothing to a file and you only see the Metrics list, if the host keeps one. Do not turn on display_errors on a public site. Mail support@webji.services with the domain if neither file exists after a fatal you can reproduce.

Deeper debugging with Query Monitor

Query Monitor is a plugin that shows database queries, PHP errors and hooks inside the WordPress admin while you are logged in. It does not create debug.log and it does not help when the admin itself will not load.

Use it when the site opens but one screen is slow or a notice appears only for administrators. Remove the plugin when you are finished. It is not a substitute for the file log on a white screen.

Turning debugging off (security)

Set WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY back to false on a live site. A leftover debug.log can be requested in a browser if the folder allows it, and it can contain paths and form data.

Delete or move wp-content/debug.log after the fix. Leave PHP log_errors on so the server still records fatals. The public page should show a normal error, not a stack trace.