Your hosting account keeps several separate log files, and the one you need depends on what's broken. PHP errors, web server access, and WordPress-specific issues each write to a different log, and most are readable straight from cPanel without needing FTP or SSH.
If you're chasing a specific symptom rather than browsing logs generally, start with the error log; it usually names the file and line where something failed.
PHP error logs
PHP errors are logged by default, even though they're not displayed on the page (that's intentional; see the note on display_errors below).
In cPanel, go to Metrics > Errors to view these in the browser without needing an FTP client. If logging looks like it's off (no entries even when you can reproduce the problem), check log_errors = on and the error_log path under Software > MultiPHP INI Editor, in either Basic or Editor mode. The full walkthrough, including how to safely turn on display_errors for a debugging session without leaving it on in production, is in enabling error logging.
Access logs
Access logs record every request that hits your site: URL, timestamp, IP, status code, user agent. In cPanel, they're under Metrics > Raw Access.
These are the ones to pull when you're trying to figure out whether a spike in traffic was real visitors or a bot crawling aggressively, when you need to confirm a specific request actually reached your server (versus getting blocked upstream), or when you're correlating a status code like a 404 or 403 back to the exact URL and referrer that triggered it. If you're proxied through Cloudflare, keep in mind the access log only shows what reached your origin server; anything Cloudflare served from cache or blocked at the edge won't appear here. For a 502 or 504 specifically, see fixing 502 and 504 gateway errors.
WordPress debug log
WordPress has its own logging layer, separate from the PHP error log, and it's off by default. Turn it on by adding this to wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
This writes to /wp-content/debug.log, viewable through File Manager or FTP. Keeping WP_DEBUG_DISPLAY set to false means errors get logged but never printed to the page, so it's safe to leave on a live site briefly without exposing internals to visitors. Turn WP_DEBUG back off once you've found what you needed; a growing debug log is easy to forget about.
A quick way to narrow down where to look
- Site behaving oddly, PHP warnings suspected, or a white screen: check the PHP error log first.
- Site down or returning an error code to visitors: check the access log to confirm what visitors are actually hitting, then cross-reference the error log for the same timestamp.
- Something's off specifically inside WordPress (a plugin conflict, a broken hook): enable and check the WordPress debug log.
- Site may be compromised instead of broken: logs won't confirm or rule out malware on their own; see scanning your website for malware.
When to open a ticket
If you've checked the relevant log and the entries don't make sense, or the log file itself is missing when it shouldn't be, open a ticket from the portal under Support. Paste the exact log lines around the time of the issue; a real person looking at the actual error text can usually help faster than a description of the symptom alone.