How to Find and Read Error Logs in cPanel

Half the support tickets we see start with "my site is broken" and nothing else. The fastest way to stop guessing and start fixing is the error log — cPanel keeps several, and most people never open them. Here's where they live and what to actually do with them.

Where cPanel Keeps Your Error Logs

There isn't one single log file. cPanel and the server underneath it write to a few different places depending on what went wrong:

• Errors page — cPanel > Metrics > Errors. This shows the last 300 lines of your domain's Apache/PHP error log, no file access needed.
• PHP error log — usually /home/username/public_html/error_log (or in the specific subdirectory where the error happened). This is where uncaught PHP errors, warnings, and notices land once logging is turned on.
• Raw access logs — cPanel > Metrics > Raw Access, or files under /home/username/access-logs/. Every single HTTP request to your domain, including the ones that returned 404s and 500s.
• WordPress debug log — /home/username/public_html/wp-content/debug.log, only exists if you've turned on WP_DEBUG_LOG.

Start with the Errors page. It's the quickest read and covers most day-to-day breakage.

Reading the Errors Page

Log in to cPanel, go to Metrics > Errors, and pick the domain from the dropdown if you have more than one. You'll see entries that look like this:

[Tue Jul 15 09:12:04.221944 2026] [php7:error] [pid 28471] [client 103.21.244.10:0] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /home/username/public_html/wp-content/themes/mytheme/functions.php:112

Break it down left to right: timestamp, module (php7:error means this came from PHP, not Apache), the visitor's IP, then the actual error. In this example, a theme function is calling a WooCommerce function on a site where WooCommerce is deactivated — that's the fix, right there in one line.

The Errors page only shows the most recent lines and doesn't retain history long-term, so if you're chasing an intermittent issue, you need it turned into a proper log file.

Turning On Full PHP Error Logging

If the Errors page is empty or too thin to be useful, PHP logging is probably set to a low verbosity. Fix that from MultiPHP INI Editor in cPanel:

1. Go to Home > Software > MultiPHP INI Editor.
2. Select your domain, switch to Editor Mode.
3. Set display_errors = Off (never show raw errors to visitors), log_errors = On, and error_reporting = E_ALL.
4. Set error_log to a path you control, e.g. /home/username/public_html/error_log.
5. Save. No restart needed — PHP-FPM/suPHP picks it up on the next request.

For WordPress specifically, you get a cleaner, WP-aware log by editing wp-config.php instead:

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

Reproduce the problem, then check wp-content/debug.log. Turn WP_DEBUG back off once you've got what you need — it's noisy and slightly slows things down if left on permanently.

Tailing the Log Instead of Reloading a Page

If you have SSH access, don't refresh cPanel's Errors page fifty times — just tail the file and reproduce the issue once:

tail -f /home/username/public_html/error_log

Or filter for one keyword across everything:

grep -i "fatal" /home/username/public_html/error_log | tail -30

This is the single biggest time-saver for anyone debugging a live site — you see the exact moment the error fires instead of hunting through hundreds of unrelated lines afterward.

Raw Access Logs: When There's No PHP Error at All

Sometimes the problem isn't PHP throwing an error — it's a 403, a 404 on assets, or a bot hammering your site. That's what raw access logs are for. Go to Metrics > Raw Access, download the current log for your domain, and grep it:

grep " 500 " access-log | tail -20
grep " 403 " access-log | awk '{print $1}' | sort | uniq -c | sort -rn

The second command counts how many requests each IP made that got a 403 — useful for spotting a single abusive IP versus a broken permission on a specific file.

Common Entries and What They Actually Mean

If You're on a VPS Instead of Shared cPanel

Without cPanel's UI, the logs are just files on disk. For Apache: /var/log/apache2/error.log (Debian/Ubuntu) or /usr/local/apache/logs/error_log (CloudLinux/cPanel-based VPS). For Nginx: /var/log/nginx/error.log. PHP-FPM has its own pool log too, usually under /var/log/php8.1-fpm.log — check the version number matches what you're actually running.

Prevention: Keep Logging On, Just Not Loud

Leave log_errors = On permanently — it costs you nothing in performance and saves hours the next time something breaks. What you shouldn't leave on is display_errors, which prints raw PHP errors (including file paths and sometimes database details) straight to visitors. That's a security leak, not just an ugly page. Log quietly, display nothing, check the file when something's wrong.