Every troubleshooting session starts in the logs. If your site is throwing errors, returning bad status codes, or getting hit by suspicious traffic, the answer is almost always sitting in a log you haven't opened yet. In cPanel, the fastest path is Metrics > Errors for a quick look at PHP errors, or Metrics > Raw Access for the full request log if you want to search or download it.
Where the logs actually live
There are two separate log types, and mixing them up wastes time.
- PHP error log: every PHP error on the account, viewable in cPanel under Metrics > Errors.
- Access log: every request that hit your site (IP, timestamp, path, status code, user agent), viewable in cPanel under Metrics > Raw Access.
Metrics > Errors shows the error log in the browser without needing FTP or SSH. That's usually the fastest way to check after something breaks. On most hosting accounts, PHP errors are suppressed from the page and written to the log instead, which is the correct production setting. If you're not seeing entries where you expect them, see enabling error logging for how to turn logging back on.
Reading the PHP error log
Each line has a timestamp, an error type (Notice, Warning, Fatal error), a message, and usually a file path plus line number. Fatal errors are the ones worth chasing first, since they're what actually breaks a page. A line like:
PHP Fatal error: Uncaught Error: Call to undefined function foo() in /home/user/public_html/wp-content/plugins/example/example.php:42
tells you exactly which file and line to open. Warnings and notices are noisier and often harmless (a missing array key, a deprecated function call), but a sudden flood of them right before a fatal error is worth reading too, since it can show the chain of events that led to the crash.
If you're chasing a 500 error, the log almost always names the cause directly, things like a script running out of memory, hitting the execution time limit, or a plugin calling something that no longer exists. See fixing a 500 Internal Server Error for how to match specific log messages to fixes.
Reading the access log
Access logs follow the standard combined log format:
203.0.113.42 - - [30/Sep/2026:14:22:01 +0000] "GET /wp-login.php HTTP/1.1" 200 3421 "-" "Mozilla/5.0"
That's the visitor's IP, the timestamp, the request line (method + path), the status code, response size, referrer, and user agent. A few patterns worth watching for:
- Repeated requests to
wp-login.phporxmlrpc.phpfrom many different IPs usually means a brute-force attempt, not a real user problem. - A burst of 403s from one path often lines up with a permissions or
.htaccessissue; see fixing a 403 Forbidden error for how to trace it back. - A wall of requests to the same URL in the same second points to a bot or scraper rather than a person, which matters if you're trying to explain a bandwidth or CPU spike.
Because access logs record everything, they get large fast on busy sites. If you're pulling them via FTP or SSH to search locally, grep for the status code or path you care about rather than scrolling the whole file:
grep " 500 " yourdomain.com_access_log
WordPress-specific logging
If the site is WordPress and PHP's own error log isn't specific enough, WordPress has its own debug log that records plugin and theme errors with more context. That's a separate setup step covered in enabling error logging, including where the file lands and how to turn it off again once you've found what you needed.
When to contact support
If you've read the error log and the message points at something outside your code, like a missing PHP extension, a server-level limit, or a gateway error that doesn't clear up at the origin, open a ticket from the portal (Support) or use live chat. Include the exact log line and timestamp; a real person can check server-side logs your account doesn't have access to and usually resolve it faster with that in hand.