cPanel Error Logs and Debugging – Finding Why Things Break

When a site stops working, the error logs almost always contain the answer. Browser-side you see a generic “500 Internal Server Error” or a white screen; server-side, your error log has the exact PHP fatal, the line number, the file. This guide shows where to find logs, what to look for, and how to debug WordPress and PHP issues using them.

The three logs that matter

cPanel → Metrics → Errors

The fast first stop. Shows the last 300 Apache/PHP error log entries for your account. Each entry has a timestamp, severity, and message.

Reading entries:

• [date and time] — when the error happened.
• [error level] — Notice (informational), Warning (something wrong but proceeding), Error (operation failed).
• [client IP] — which visitor triggered the error.
• [message] — the actual error.

For most “site broken” diagnostics, scrolling to the most recent few entries identifies the cause within 30 seconds.

error_log files in your account

PHP automatically writes errors to a file called error_log in the same folder as the script that errored. After a problematic page request, look for that file.

To find them all:

1. cPanel → File Manager.
2. Settings → Show Hidden Files (turn on if you haven’t).
3. Navigate to public_html or the affected subfolder.
4. Look for a file literally named error_log.
5. Right-click → View.

If you have SSH access:

find ~/public_html -name error_log
tail -50 ~/public_html/error_log

error_log files can grow large over time — delete them periodically once you’ve reviewed and addressed the errors.

Reading common PHP errors

Fatal error: Allowed memory size exhausted

Sample:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 8192 bytes) in /home/user/public_html/wp-content/plugins/heavy-plugin/file.php on line 245

Means: PHP ran out of memory. The 134217728 = 128 MB. Solutions:

• cPanel → Select PHP Version → Options → raise memory_limit to 256M or 512M.
• If problem persists at high limits, the plugin/script has a memory leak — investigate or replace.

Fatal error: Uncaught Error: Call to undefined function

Sample:

PHP Fatal error: Uncaught Error: Call to undefined function mysqli_connect() in /home/user/...

Means: a required PHP extension isn’t loaded. cPanel → Select PHP Version → Extensions → enable the missing one (mysqli, curl, gd, etc.).

Maximum execution time exceeded

PHP Fatal error: Maximum execution time of 30 seconds exceeded in /home/user/...

Script ran longer than the limit. Solutions:

• Raise max_execution_time in PHP options (60, 120, 300 seconds).
• Or optimize the script — long-running processes should be cron jobs, not page requests.

Parse error / syntax error

PHP Parse error: syntax error, unexpected '}' in /home/user/.../file.php on line 47

You (or an editor) introduced a syntax error. Open the file at the noted line, fix the syntax. Usually a missing semicolon, unmatched brace, or stray character.

“Headers already sent” warning

Warning: Cannot modify header information - headers already sent by (output started at /home/user/.../wp-config.php:1)

Means: output (whitespace, BOM, echo) happened before a redirect/header call. Common with edited wp-config.php — usually whitespace before <?php or after ?>. Open the file, remove whitespace.

WordPress debug mode

For deeper WordPress debugging, enable WP debug. Edit wp-config.php, find WP_DEBUG line, and replace with:

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

Effect:

• WP_DEBUG true — enables WordPress’s debug logging.
• WP_DEBUG_LOG true — writes errors to wp-content/debug.log.
• WP_DEBUG_DISPLAY false — hides errors from page output (so visitors don’t see them).

Now reproduce the problem, then check wp-content/debug.log for the detailed error.

Disable debug mode after fixing — set WP_DEBUG back to false. Debug logging slows the site and can leak info.

Diagnosing 500 errors

“500 Internal Server Error” is generic — actual cause is in logs. Common causes:

• .htaccess syntax error. Check Metrics → Errors for “Invalid command” or “syntax error”. Fix the bad line or revert .htaccess.
• PHP fatal in your code. Check error_log; fix the offending file.
• File permissions wrong. Scripts world-writable (777) or unreadable. Run permissions reset.
• Out of memory. See memory_limit fix above.
• Plugin or theme conflict (WordPress). Try disabling plugins via phpMyAdmin (set active_plugins to a:0:{}).

Diagnosing white screen of death (WordPress)

Site loads blank — no error visible. Usually:

1. Enable WP_DEBUG_LOG as above.
2. Reload the blank page.
3. Check wp-content/debug.log.
4. The most recent entry is your culprit — usually a plugin’s fatal error or PHP version incompatibility.

If WP_DEBUG_LOG isn’t catching anything (rare), check the directory error_log file directly.

Visitor / access logs

cPanel → Metrics → Latest Visitors. Shows recent HTTP requests with status code. For each request:

• 200 = success.
• 301/302 = redirect.
• 404 = not found.
• 500 = server error.
• 403 = forbidden.

Useful for “which URL is generating 500s” — visible at a glance, with the visitor’s IP and user agent.

For full access logs: cPanel → Metrics → Raw Access → download archived logs (one per day).

Mail logs

Separate from web error logs. For mail delivery issues: mail logs and bounces guide.

Common log issues

“Errors page is empty even though site is broken.” Some errors don’t reach the cPanel Errors view if PHP can’t even start. Check directory-level error_log files; check WordPress’s wp-content/debug.log.

“Same error repeats hundreds of times.” Single broken page being hit repeatedly. Fix the underlying issue rather than scrolling past duplicates.

“error_log file is huge.” A loud error firing on every page request. Find the root cause (often a deprecated PHP function in an old plugin) — silencing isn’t the answer.

“Want logs older than what’s shown.” Raw Access archives go back 30-90 days typically. Older than that, ask support.

What’s next

• PHP settings that cause many errors: PHP version and settings.
• WordPress-specific debugging: enable WP_DEBUG, check plugins one at a time.
• If errors trace to mail delivery: Mail logs guide.

Error logs answer 90% of “why is my site broken” questions in under a minute. Make checking cPanel → Metrics → Errors the first step when anything goes wrong — you’ll skip a lot of guessing.