When a site breaks, the error log usually already contains the answer. The difficulty is that there are several logs, they contain different things, and the one people open first is frequently the wrong one. A PHP fatal error and a 500 response can look identical in a browser and appear in entirely different files.
This covers which log holds which kind of failure, how to read an entry once you find it, and the errors you will meet most often.
The logs, and what lives in each
The account error log is the one in cPanel under Metrics then Errors. It shows recent web server errors for your account: files that could not be found, permission problems, and requests the server refused. It is the right starting point for a 403 or a 404 that should not be happening.
The PHP error log holds application failures: fatal errors, warnings and notices from your code or a plugin. Depending on configuration it lands in a file in the account or alongside the script. This is where a white page comes from.
The application's own log. WordPress writes to wp-content/debug.log when debugging is enabled, and it is far more informative than anything else for a WordPress problem. Turning it on is the single most useful step when a WordPress site misbehaves.
Access logs record every request. They are not error logs, but they answer questions the error log cannot: whether a request even arrived, where traffic came from, and what a bot was doing before things went wrong.
Reading an entry
A log line has four useful parts: when it happened, how serious it is, what happened, and where. The last one is what you act on.
[19-Aug-2026 14:32:07 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wp_get_theme() in /home/user/public_html/wp-content/plugins/example/init.php:42
The file path and line number name the responsible code. Here it is a plugin, so the plugin is the problem regardless of how the symptom presented.
The severity word matters more than people assume:
- Fatal error stopped execution. This is your problem.
- Warning did not stop anything but usually indicates something wrong.
- Notice and Deprecated are almost always noise. Sites produce thousands of these while working perfectly.
Read from the bottom. Logs append, so the newest entries are last, and the one that matters is the one written when you reproduced the problem.
Reproduce, then read
The most efficient technique with any log is to make the error happen on purpose.
Note the current time. Load the broken page. Open the log and look at entries from the last minute. Everything older is history, and a busy log contains a great deal of history that has nothing to do with today.
Without this, you are reading a file full of unrelated warnings and guessing which line corresponds to the problem in front of you.
Turning on WordPress debugging
For a WordPress site, this is worth doing before anything else. Add to wp-config.php, above the line telling you to stop editing:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG_DISPLAY set to false is essential on a live site, errors go to wp-content/debug.log rather than appearing on the page for visitors.
Reload the broken page, read the log, then turn all three off again. Leaving debug logging on grows the file without limit, and it can expose paths if the display setting is ever flipped.
Fixing common WordPress errors explains what to do once the log has named the file.
Errors you will meet often
Allowed memory size exhausted. The named file is usually innocent. It was simply running when memory ran out. Raise the limit, but treat repeated occurrences as a symptom rather than something to keep raising away.
Permission denied. Files should be 644 and directories 755. If uploads fail, the cause is normally ownership rather than permissions, and 777 is never the fix. It converts an inconvenience into a full compromise.
File does not exist. Very common and usually harmless: bots requesting wp-login.php on sites without WordPress, or a missing favicon. Worth attention only when it names a file your own pages request.
Maximum execution time exceeded. A script ran longer than allowed. Common in imports and backups. The fix is usually to do the work in smaller pieces rather than to raise the ceiling.
Error establishing a database connection. Credentials, or a database user without privileges on the database. Configuration rather than code.
An empty log is information
If a page fails and no log entry appears, the failure happened somewhere that log does not cover.
For a 500 with an empty PHP log, suspect .htaccess. Rename it to .htaccess-old and reload; if the site returns, regenerate the rules by saving the permalink settings in WordPress.
If several unrelated sites fail at once, it is not your code. That is a server-level problem and a support ticket in place of an afternoon of debugging.
Keep the noise down
A log full of deprecation notices is a log nobody reads, including you at the moment it matters.
Fix or replace the plugin generating thousands of warnings rather than learning to scroll past them. And rotate or clear large log files periodically. A log that has grown to gigabytes is both unusable and a quiet consumer of the disk quota you are paying for.
Two faults never reach the error log at all, because nothing failed: source code shown instead of being run, and a file that downloads instead of displaying. Apache Handlers and MIME Types in cPanel goes into both.
Some answers are not in the account's logs at all but in the server's, Where Server Logs Live and How to Read Them maps which file answers which question.