When something breaks on a site, most people do the same thing: reload, try another browser, disable plugins blindly, and end up filing a ticket that says "it does not work." Meanwhile, on the server, there is a file that recorded exactly what happened, at what time, who caused it, and with which error. Learning to read it completely changes how you solve problems: you go from guessing to knowing.
The two logs that matter
Every web server keeps at least two log files. The access log records every request that arrives, whether it succeeded or failed. The error log records only what went wrong, with the technical detail of why.
The practical rule is simple: if the site looks broken or throws a 500, start with the error log. If you want to understand where traffic comes from, why the server is slow, or who is trying to get in, start with the access log.
Where to find them
On cPanel hosting there are three routes. The first is the metrics section of the panel, which usually offers a viewer for recent errors and a download of the raw logs. The second is the file manager, looking for a logs folder inside the account directory. The third, if you have command line access, is reading the file directly.
WordPress can also keep its own log if you enable it. That is useful because it records PHP errors with the exact file and line, something the general server log sometimes omits.
Anatomy of an access log line
A typical line looks roughly like this:
190.55.12.4 - - [17/Aug/2026:14:22:31 -0300] "GET /blog/my-article/ HTTP/1.1" 200 45213 "https://google.com/" "Mozilla/5.0..."
From left to right: the address of whoever requested it, the date and time with timezone, the method and path requested, the response code, how many bytes were sent, which page they came from, and which browser or bot they used.
Of all those fields, the one that solves the most problems is the response code. A 200 means it went fine. A 404 means the resource does not exist. A 301 or 302 means there was a redirect. A 403 means the server refused on permissions. A 500 means something blew up server-side. And a 503 means the service was unavailable, typically from overload.
How to search without drowning
An access log for a site with moderate traffic runs to tens of thousands of lines per day. Opening the whole thing is useless. The technique is filtering.
If you have command line access, searching for every line containing a specific error code leaves you with only the relevant cases. Counting how often each address appears instantly shows whether someone is hammering the server. And filtering by a specific path tells you whether the problem affects one page or the whole site.
If you only have the panel, download the log and open it with a text editor that handles large files, using search for the same purpose. Do not open it in a spreadsheet: it will hang.
Patterns you will recognize immediately
Automated scanning. Hundreds of consecutive 404s from the same address, requesting paths that never existed: admin panels for other platforms, configuration files, database dumps with generic names. That is a bot rattling doorknobs. Annoying, but normal on the internet.
Brute force. A flood of requests to the login page, almost always via POST, from one or several addresses. If you see this, it is time to limit attempts and enable two-factor authentication.
The broken internal link. A repeating 404 whose referrer field points to a page of your own. That means you are linking to something that does not exist. It is one of the most useful findings: a one-minute fix that improves the real experience.
The bot eating your server. A user agent identified as a crawler requesting thousands of pages per hour. It could be a legitimate search engine crawling too fast, or a scraper copying your content. In the first case you adjust the crawl rate; in the second, you block it.
The error log, where the answer actually lives
This file is shorter and far denser. Each line usually carries the date, the severity level, the message and, for PHP errors, the file and line number where it happened.
That last detail is pure gold. When the site shows a blank screen and the log says there was a fatal error in a specific plugin file at line 314, you already know what to disable. Without the log you would be switching plugins off one by one for half an hour.
The most common messages and what they really mean: allowed memory exhausted means you need to raise the memory limit or find what is eating it. Maximum execution time exceeded means a process takes longer than permitted. Failure to open a file is usually a permissions problem or a mistyped path. And a syntax error almost always comes from a recent manual edit.
Telling warnings apart from real problems
A healthy error log still has noise. You will see deprecated function notices, notes about undefined variables, and warnings from old plugins. None of that breaks the site.
What matters are fatal errors, which stop execution, and messages repeating hundreds of times, because even if they are only notices, writing to the log also costs time and disk. A plugin generating ten thousand warnings per hour is hurting your performance even if the site looks fine.
A diagnostic routine that works
When something fails, follow this order. First, reproduce the problem and note the exact time. Second, open the error log and look for that time: the cause is usually right there, literally written out. Third, if the error log says nothing, check the access log and see which code that request returned, because that tells you which layer the problem is in. Fourth, if the code is 500 but the log is empty, check the server rules file, which is the most frequent cause of a silent 500.
Those four steps resolve the vast majority of incidents without touching anything blindly.
A word about support tickets
If after reading the logs you still need to open a ticket, paste the relevant lines into the message. The difference between "my site is down" and "I get a fatal error in this file, line 314, at 14:22" is enormous: the first generates three rounds of back-and-forth before anyone looks at anything, the second gets solved on the first reply.
It is also worth choosing a host where logs are accessible without asking permission. At BanaHosting you get them from the panel itself, with the error viewer and raw log downloads, so you can run this diagnosis yourself at any hour without waiting for someone to send them over.