How to Check Server Logs on Linux and Find What Actually Broke

Your site is broken, the browser is vague, and the server feels like a locked room with smoke coming under the door.

Short version: On Linux, most server logs live in /var/log, and many modern services also write to journalctl, the system log viewer. To find what actually broke, start with the symptom, check the matching log, read the newest lines first, and look for exact messages like 502 Bad Gateway, permission denied, connection refused, or No space left on device.

If you searched for how to check server logs linux, the goal is not to read every line. The goal is to find the one line that explains the mess.

Where are server logs on Linux?

Think of server logs like the notebook behind the counter in a small shop. Every important system writes down what it tried to do, what worked, and what failed.

On many Linux servers, those notebooks live in /var/log. Common examples include:

• /var/log/syslog for general system events on Ubuntu and Debian-like systems
• /var/log/auth.log for logins, SSH attempts, and authentication problems
• /var/log/nginx/error.log for nginx web server errors
• /var/log/apache2/error.log for Apache web server errors
• /var/log/mysql/error.log or a similar database log for MySQL and MariaDB issues

Some services do not write mainly to files. They write to the system journal instead, which you read with journalctl. That sounds fancy, but it is just another notebook: one shared place where services record what happened.

The important point is this: there is rarely one magic log. There are several logs, and each one belongs to a different part of the machine.

Which log should you check first?

Start with what the user sees. Logs make more sense when you follow the same path as the request.

If the website does not load at all, first ask whether the problem is network, web server, or app. That is the same three-layer thinking from Why isn't my website loading?. A DNS or firewall issue may not show up in your application log because the request never reached the app.

If the browser shows 502 Bad Gateway, check the web server log first, usually nginx or Apache. A 502 Bad Gateway often means the front door answered, but the app behind it did not. Picture a restaurant host saying, sorry, the kitchen is not responding.

If login suddenly fails, check /var/log/auth.log. If uploads fail, check the app log and disk space. If everything is slow, logs may show repeated retries, database timeouts, or memory pressure, but you should also compare that with the resource checks in Why Is My Server Slow?.

A good rule: read the log closest to the visible symptom, then move inward.

How do you read a log without getting lost?

A log file can look like a wall of small print. Do not read it like a book. Read it like a detective looking at security camera footage around the time something broke.

First, check the time. If the site failed at 14:05, the most useful lines are usually just before and after 14:05. Old errors can be real, but they may not be today’s problem.

Second, read from newest to oldest. Many people start at the top of the file and drown in ancient history. The useful clue is often near the end.

Third, search for strong words:

• error
• failed
• denied
• timeout
• refused
• killed
• No space left on device

Fourth, copy the exact error string. Not your summary of it. The literal text matters. permission denied points in a different direction from connection refused, and No space left on device is very different from a bad password.

Finally, look for the first failure, not the loudest one. One broken database connection can cause twenty web errors afterward. The first domino is what you want.

What do the scary log messages usually mean?

Some log messages sound worse than they are. Others are plain warnings that something is about to fail.

permission denied means a process tried to read or write somewhere it was not allowed to. Imagine a cleaner with the wrong key. The person is in the building, but not allowed into that room.

connection refused means one service tried to call another, but nobody answered on the expected door. This often happens when an app is down, a database is not listening, or a service is using the wrong port.

timeout means the call did not fail immediately. It waited, and waited, then gave up. Timeouts often point to slow databases, overloaded apps, network trouble, or outside services not responding.

No space left on device means the disk is full. This can break uploads, databases, sessions, package updates, and even logging itself. It is the server version of trying to keep writing in a notebook that has no pages left.

killed can mean Linux stopped a process because the server ran out of memory. If you see this near app crashes, memory is a strong suspect.

If you run apps in containers, there may be one more layer. Docker keeps its own logs for containers, so the app’s problem may be inside the container rather than in the main system log. If that distinction is still fuzzy, this beginner guide to Docker on a server may help.

FAQ

What is the main command for checking Linux server logs? Use journalctl for systemd service logs, and read files under /var/log for traditional log files.

Which log shows SSH login attempts? On Ubuntu and Debian-like systems, check /var/log/auth.log for SSH logins, failed passwords, and authentication messages.

Where are nginx errors stored? Commonly in /var/log/nginx/error.log, though the exact path can vary if the server was configured differently.

Should I delete large log files when the disk is full? Be careful. Deleting the wrong file may not free space until the service is restarted, and you may lose clues. Find what is growing first.

The shortcut

Server Manager helps by keeping the shape of your server understandable, so the logs are not a pile of mystery notes months later. When a site breaks, you are not trying to remember which project owns which domain, which service belongs to which app, or whether one project quietly depends on another.

That matters for the same failures this post covered: a 502 Bad Gateway because the app behind nginx is not healthy, a site failing because disk space ran out, or one project breaking another because the setup became hard to read. The real benefit is not avoiding every error. It is making the error easier to place.

Over time, that legibility saves you from guessing. You can come back after a quiet month and still understand what is running, what it belongs to, and where to look first when the logs start shouting.

Logs are not there to make you feel technical. They are there to replace panic with a trail. Once you know where to look, read the newest lines first, and trust the exact error string, you stop fixing random things and start fixing the thing that actually broke.