Read Your Server Logs and Diagnose Faults in Under 5 Minutes

Where server logs live and how to start diagnosing

When your site goes down or slows, the logs are the first place to look, not the control panel and not guesswork. The server writes every request and every failure into two core files: the access log records every HTTP request that reached the server, and the error log records everything that failed internally. On Apache with cPanel, per-domain access logs sit in /home/USER/access-logs/ and account errors in /home/USER/logs/, with the global log at /usr/local/apache/logs/access_log. On Nginx the defaults are /var/log/nginx/access.log and /var/log/nginx/error.log. PHP errors get their own file, usually /home/USER/logs/php_errors.log or wherever error_log points in php.ini.

The rule that saves you hours: open the error log first to learn what failed, then open the access log to learn who requested it and when. Roughly 80% of site problems reveal themselves in the last line of the error log alone. The fastest way to watch errors as they happen is tail -f on the error file, which streams each new error the instant it is written. In this guide we break down an access log line and an error log line field by field, walk through ready commands you can copy, and cover the ten most common error patterns with a diagnosis for each. On Cloud servers in Riyadh these logs reach you at around 8ms latency, so you read them from inside the Kingdom with none of the roughly 120ms delay of a foreign server.

Anatomy of an access log line

The default access log follows the Combined Log Format, nearly identical across Apache and Nginx. Take this real example:

203.0.113.45 - - [14/Aug/2026:09:23:11 +0300] "GET /api/orders?id=52 HTTP/1.1" 200 1843 "https://cloud.net.sa/" "Mozilla/5.0"

Read it field by field so any line becomes obvious:

• 203.0.113.45 the client IP. If it repeats thousands of times a minute, you are looking at a bot or an attack.
• [14/Aug/2026:09:23:11 +0300] the server time, where 0300+ means Riyadh time. Watch this offset if your server runs on UTC.
• "GET /api/orders?id=52 HTTP/1.1" the method and exact path requested, showing precisely which URL was hit.
• 200 the HTTP status code, the single most important number in the line. 200 is success, 500 is internal failure.
• 1843 the response size in bytes. A zero next to a success code usually means the connection dropped.
• Referer and User-Agent the traffic source and the browser or bot identity.

Status codes fall into families: the 2xx family is success, 3xx is redirection, 4xx is a client error such as 404 not found, 403 forbidden, and 429 too many requests, and 5xx is a server error such as 500, 502, 503, and 504. Any sudden spike in 5xx counts means the problem is yours, not the visitor's, and that is the first signal to chase.

Anatomy of an error log line

The error log is less structured than the access log because it collects messages from different sources, yet every line carries three valuable pieces: the time, the severity level, and the message. An Apache example:

[Thu Aug 14 09:23:11 2026] [error] [client 203.0.113.45] PHP Fatal error: Uncaught Error: Call to undefined function get_orders() in /home/user/app/index.php:88

You instantly read that this is a Fatal error, meaning execution stopped, and the guilty file and line is index.php at line 88. Severity levels rank your priorities: Fatal and error break the page and demand immediate action, while warning and notice do not halt execution but expose weak code, and on a busy server they can generate millions of lines a month and fill the disk. We have seen accounts whose error log grew past 2GB a day from a single repeating notice the developer never noticed.

Application error versus server error

Always distinguish: if the message starts with PHP or names one of your code files, the problem is in the application and belongs to your developer. If the message comes from nginx or apache itself, such as connect() failed (111: Connection refused) while connecting to upstream, the problem is in the server layer or a backend service like a stopped PHP-FPM.

Copy-ready commands for reading logs fast

Every tool here ships with any Linux server, no install needed. Memorize these five and you cover 90% of daily work:

• tail -f error_log streams errors live as they are written, ideal while reproducing the issue.
• tail -n 100 error_log shows the last hundred lines, the start of any diagnosis.
• grep " 500 " access_log filters to only the requests that returned a 500.
• grep "203.0.113.45" access_log traces everything a specific IP did.
• awk '{print $9}' access_log | sort | uniq -c | sort -rn gives a status code distribution table sorted top down.

That last command is your sharpest weapon: in one second it tells you how many requests returned 200, how many 404, and how many 500. If you see thousands of 404s, you are facing many broken links or a bot probing fake paths. To find the noisiest IP, run awk '{print $1}' access_log | sort | uniq -c | sort -rn | head, which surfaces the top ten addresses by request count, and the first line is usually the source of your load or attack. All of these run directly on a Saudi server over SSH with no foreign intermediary in the path.

Ten common patterns and how to diagnose them

A spike in 500 codes

If 500 errors jump right after a deploy, the cause is almost always new code. Open the error log immediately, and the first Fatal line hands you the file and line. More than 60% of post-deploy outages are exposed by the very first error line.

502 and 504 from upstream

A 502 or 504 with an upstream message means the web server is running but PHP-FPM or the backend stopped or stalled. Check the service status and its memory, and the fix is usually restarting PHP-FPM or raising the timeout.

A wave of 404s to strange paths

If you see hundreds of 404s for paths like wp-login, .env, and phpmyadmin that your site never uses, that is a bot scanning for known holes. Log the IP and block it at the firewall.

403 on files that should be public

A 403 is usually a file permission problem or an htaccess rule. Confirm directories are 755, files are 644, and ownership is correct.

Slowness with no error

Sometimes the site is slow while every status code is 200. Add a response time field to the log format, then sort for the slowest requests. Any request over one second deserves review, and unindexed database queries are the prime suspect in 70% of slowness cases.

Tie logs to security and performance

Logs are not only for diagnosis during an outage, they are an early warning system. Watch the rate of 401 and 403 to catch repeated login attempts, and watch back-to-back POST requests on the login page to detect password cracking. On Cloud servers the log is stored inside the Kingdom, which matters for compliance and National Access because access data stays under Saudi sovereignty and never leaves for foreign centers. Configure log rotation with logrotate so the disk never fills, since a log without rotation can halt the server once space runs out, and we have seen servers stop entirely because of a log that passed 40GB.

A practical wrap-up

Lock this order into memory for any outage: open the error log and read the last line, decide whether the error is from the application or the server, then move to the access log to learn who requested it, when, and how many times. Use grep to filter, awk to count, and tail to watch live. With practice you cut a diagnosis that took an hour down to under five minutes. And whoever runs on nearby Saudi infrastructure reads their logs at 8ms latency and acts before customers even feel the problem.