Where WordPress error logs are written
WordPress error logs land in three places. Start with wp-content/debug.log. If that file is missing, the account log under cPanel, then Metrics, then Errors, still records PHP fatals. The web server log is the third place, and on shared hosting you reach it through support.
| Log | Where you open it | What it records |
|---|---|---|
| WordPress debug.log | wp-content/debug.log | PHP errors while WordPress runs, after WP_DEBUG_LOG is true |
| Account error log | cPanel, then Metrics, then Errors | PHP errors for the account, including requests that never wrote debug.log |
| Web server log | Apache, Nginx, or PHP-FPM on a VPS | The request that failed when PHP never printed a message |
- debug.log is WordPress's own file. It is written only after WP_DEBUG_LOG is true, and only when PHP raises an error.
- The cPanel Errors screen is the account error_log. It includes lines WordPress itself never stored.
- Apache, Nginx, and PHP-FPM logs are visible on a VPS, or by emailing support on a shared plan.
Read the first fatal, not the last notice under it. The path and the line number name what stopped. A 404 is a missing URL and usually writes nothing here, because PHP did not fail. The folder layout is on where the WordPress error log file sits.
Enabling WP_DEBUG and debug.log (wp-config edit)
Turn logging on in wp-config.php, above the line that says to stop editing. Set WP_DEBUG and WP_DEBUG_LOG to true, and WP_DEBUG_DISPLAY to false. The file appears only after PHP raises an error.
- In cPanel File Manager, open public_html/wp-config.php and download a copy before you edit.
- Above the stop-editing comment, set
define('WP_DEBUG', true);. If that line already says false, change it. - Add
define('WP_DEBUG_LOG', true);so WordPress writes wp-content/debug.log. - Add
define('WP_DEBUG_DISPLAY', false);and@ini_set('display_errors', 0);so visitors never see the path. - Empty debug.log if it already exists, reproduce the fault once, then open the file with View.
You know it worked when a new line carries the time of that test. If the file never appears, PHP did not throw. Leave display off on a live site. A dashboard widget can show the same lines in wp-admin, but it still needs this file.
Reading the cPanel error_log via Metrics → Errors
Open cPanel, then Metrics, then Errors, when debug.log is empty or you need a fatal WordPress did not record. That screen is the tail of the account error_log. It is not a second copy of debug.log.
A line that contains wp-content/plugins/ and a folder name is a plugin error. Deactivate that plugin, or rename its folder if wp-admin will not open. Theme lines contain wp-content/themes/. The file on disk, and the PHP error_log setting, are in PHP error logs in cPanel.
You know it worked when the newest line matches the minute you reproduced the fault. Older lines are earlier incidents. Do not chase those first.
Decoding common errors — fatal, deprecated, warnings
A fatal stops that request, so the page is white or returns HTTP 500. A warning, a notice, or a deprecated line means PHP continued. Read the first fatal before you change any file.
| Level | What the page does | What the line means |
|---|---|---|
| Fatal | White screen or HTTP 500 | Execution stopped. The text often says undefined function, memory exhausted, or maximum execution time. |
| Warning | The page still loads | Something failed and PHP continued. Headers already sent usually names a plugin file. |
| Notice | The page still loads | Sloppy code that still ran. It is not the cause of a white screen. |
| Deprecated | The page still loads | A function PHP will remove. Common right after a PHP version change. |
Undefined function or class usually means a missing extension, or a plugin that expected another plugin to be active. Allowed memory size exhausted and maximum execution time exceeded are limit problems. Those fixes are on the WordPress 500 error page. A browser that says this page is not working, with HTTP 500, is the same symptom.
A fatal whose path contains wp-content/plugins names the plugin folder. A path in wp-content/themes names the theme. If the fatal is inside wp-login.php, the stop is that plugin or theme, not a wrong password.
Permission denied, or failed to open stream, means the file mode or the owner blocked PHP. That is not a visitor-facing 403 guide. Another host's panel is a different screen. The debug.log path is the same. This page uses cPanel.
How to turn WordPress debug logging off
Set WP_DEBUG back to false, and remove the log and display lines, once you have copied the incident. You know it worked when new page views do not add lines to debug.log.
The file sits in a public folder. Anyone who requests /wp-content/debug.log can read plugin paths. Delete the file, or deny .log in .htaccess, after you save the lines you need. Do not leave logging on a live site for a slow bug unless that file is blocked and you watch its size.
When a WordPress error log fills the disk
One plugin that writes a warning on every view can fill the account quota in a day. A sudden disk warning is often debug.log or error_log, not the media library. Stop the plugin that loops, then empty the file.
If you must keep logging for an intermittent fault, trim the file weekly. On a VPS, logrotate covers Apache or Nginx logs. debug.log is not in that job. You delete or rotate it yourself.
What to email WebJi® from a WordPress error log
Email support@webji.services the time of the test, the first fatal line, the plugin or theme folder it names, and the PHP version. Say whether the fault hits the public site, wp-admin, or both. Do not send database passwords if a line printed them.
Replies are in Hindi or English, and the average first reply is under 60 minutes. The office number +91-141-4941811 is not a support line. Do not call it to have a log read. WordPress hosting on WebJi includes cPanel, so Metrics, then Errors, is on the account before you write.
WordPress error log questions
Where are WordPress error logs located?
wp-content/debug.log holds the WordPress lines after debug logging is on. cPanel, then Metrics, then Errors, shows the account error_log. On a VPS, the web server log is the third file. Open debug.log first.
How do I enable WordPress debugging?
In wp-config.php, above the stop-editing line, set WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false. Reproduce the fault once. A new line in wp-content/debug.log means logging is on.
What is debug.log in wp-content?
It is the file WordPress creates when WP_DEBUG_LOG is true and PHP raises an error. It stays missing when nothing failed. Copy the lines you need, then delete the file so it is not left on the public site.
How do I see PHP errors in cPanel?
Open Metrics, then Errors. That list is the tail of the account error_log. Use it when debug.log is empty. Match the newest line to the minute you reproduced the fault.
What do deprecated warnings mean?
The page still loaded. PHP is warning that the named function will be removed in a later version. A flood after a PHP upgrade is common. Update the plugin or theme the path names before the next upgrade.
How do I read a fatal error stack trace?
Start at the first line that says Fatal error or Uncaught. The path and the number after it are where PHP stopped. Lines under that are the calls that led there. A path inside wp-content/plugins names the plugin folder.
Does a WordPress 404 or HTTP 500 show in the error log?
A 404 usually does not, because the URL never caused a PHP failure. HTTP 500, including a browser message that the page is not working, should leave a fatal in debug.log or in the cPanel Errors screen for that minute.