journalctl: how to read server logs and find the error in a minute

A site returns 502, a service refuses to start, someone is hammering SSH. In all three cases you start with the journal. On current Ubuntu and Debian there is one journal for the whole system and one command to read it, journalctl. Here is how to pull out exactly what you need without drowning in thousands of lines.

In short. sudo journalctl -u service_name -n 50 shows the last 50 entries of one service. -p err -b keeps errors since the last boot, --since and --until set a time range, -g searches text and -f follows new lines. Without sudo a regular user sees only their own entries. journalctl --disk-usage shows the size and --vacuum-size shrinks it.

What the journal is and where it comes from

The journal is a single store for messages from systemd, the kernel and every service. It is kept by systemd-journald: a program prints a line, journald saves it with the service name, a timestamp and a priority. So instead of a dozen files in /var/log you ask one source. First check how big it is:

Nine megabytes on a server that has been running for a week is a normal figure. The journal is usually persistent when the /var/log/journal directory exists, so entries survive a reboot. To see how many boots it remembers, run journalctl --list-boots. Our server has not been rebooted since 4 October, so the list has one row.

Why you see almost nothing without sudo

Run journalctl as a regular user and the output starts with a hint:

This is not an error. The journal is closed to other eyes because it can contain addresses, user names and pieces of requests. You have two options: put sudo in front of the command or add your user to the systemd-journal group. For one-off debugging sudo is enough, and every example below uses it.

One service: the -u flag

Most of the time you need one service, not the whole system: nginx, ssh, docker. The -u (unit) flag keeps only its entries, and -n 4 prints the last four lines, otherwise you get the whole history from the first day:

--no-pager prints everything at once instead of opening a scrollable view, which is easier to copy. These are our own logins: Accepted publickey means the user came in with a key, and the next line marks the start of the session. But on any server with SSH open, the same journal holds something else: strangers try root and guest every few minutes. How to stop that is covered in fail2ban for SSH.

To find a service name, use systemctl list-units --type=service. On Ubuntu the SSH service is called ssh, on some other systems sshd.

Errors only: the -p flag

Every entry has a priority from emerg (0) to debug (7). -p err prints errors and anything more severe, and -b limits the output to the current boot. This shows what has gone wrong since startup:

Every error here comes from scanners that dropped the connection halfway. On a healthy server that is background noise. It gets worrying when lines about nginx, the database or a full disk show up in this list.

A time range: --since and --until

You often know when it broke: "after lunch" or "last night". Give the boundaries and the rest drops out. Time can be written as "2026-10-12 11:00", as yesterday, or relatively, such as "-2h" and "10 min ago":

Timestamps use the server time zone, not yours. If you compare against a log on your laptop, check the zone with timedatectl.

Search by text: the -g flag

-g filters lines by a pattern and fits when you know a phrase from the error. It accepts regular expressions and combines with the other flags. For example, find failed password logins in the SSH journal:

These lines are dated 4 October, the day this server was reinstalled, when password login was still on. We turned passwords off afterwards and there are no newer entries of this kind. The journal remembers such things, so it is a handy way to confirm a security change actually worked.

Kernel and firewall: the -k flag

-k shows kernel messages only, like dmesg but with proper history. This is where firewall drops and out-of-memory (OOM) kills are logged. If you set up ufw and want proof it is dropping the extras:

The [UFW BLOCK] tag means a firewall rule dropped the packet. SRC is where it came from and DPT is the port it knocked on. Here these are unsolicited hits on ports 8888 and 23212, which are closed on our server. If you see lines like this, the firewall is working.

Follow the journal live: the -f flag

-f (follow) works like tail -f: the command keeps running and prints new entries as they appear. This is the main trick when you restart a service and want to see right away what it says:

sudo journalctl -u nginx -f

Stop it with Ctrl+C. If a site returns 502 or 504, keep one window on -f, repeat the request in another and watch which line appears. These codes are explained in nginx errors 404, 502, 504 and 413.

How much space the journal takes and how to shrink it

The journal is not endless. On a busy server it can grow to hundreds of megabytes, and on a small disk that matters. --disk-usage shows the size. You can trim it once or set a permanent cap:

• sudo journalctl --vacuum-size=200M deletes the oldest entries until the journal is under 200 MB;
• sudo journalctl --vacuum-time=14d keeps the last 14 days;
• a permanent cap is the line SystemMaxUse=200M in /etc/systemd/journald.conf; restart afterwards with sudo systemctl restart systemd-journald.

Do not delete files in /var/log/journal by hand, you can leave the journal in an inconsistent state. The three options above do the same safely. If the disk is full anyway, the journal is rarely the cause, so measure what takes the space first.

Cheat sheet

FAQ

How do I view a service's logs in Linux?

Run sudo journalctl -u service_name -n 50 for the last 50 entries. Add -f to follow new ones. Find service names with systemctl list-units --type=service.

How do I show only errors?

Use sudo journalctl -p err -b. -p err keeps errors and anything more severe, and -b limits the output to the current boot.

Can I clear the journal?

Yes, the supported way is sudo journalctl --vacuum-size=200M or --vacuum-time=14d. Do not delete files in /var/log/journal by hand.

Why does journalctl say "You are currently not seeing messages from other users and the system"?

You ran it without privileges. Add sudo or put your user in the systemd-journal group.

Where are the nginx logs if journalctl only shows starts and stops?

The journal holds the service's own messages. The access log and the site error log of nginx go by default to /var/log/nginx/access.log and error.log.

Summary

• One journal for the whole system, read with journalctl, usually with sudo.
• One service is -u, errors are -p err -b, a range is --since and --until, text is -g, kernel and firewall is -k, live is -f.
• Background noise from SSH scanners on an open server is normal; errors from your own services are not.
• Check size with --disk-usage, trim with --vacuum-size or SystemMaxUse, and never delete files by hand.

🎁 40% off the first month of a new VPS. Promo code GUIDE40
Logs are easiest to learn on a server of your own. First month at a discount.
Enter GUIDE40 at checkout. One use per customer.
Pick a VPS and claim the discount →