How to Read and Manage Linux Logs with journalctl

On modern Linux, systemd's journal is the central log store — SSH, your web server, cron, the kernel, and most services all write to it. journalctl is how you read it. Learn a handful of filters and you can go from "something's broken" to the exact error line in seconds. This guide covers the commands you'll use daily.

The basics

Show the whole journal (newest at the bottom), and jump straight to the end:

journalctl              # everything, paged
journalctl -e           # jump to the end
journalctl -n 50        # last 50 lines

Add -r to reverse (newest first). Most journal reads need sudo to see other users' and system logs.

Follow logs live

The equivalent of tail -f, for watching a problem as it happens:

journalctl -f

Filter by service — the one you'll use most

Zero in on a single unit:

journalctl -u ssh
journalctl -u nginx -f

This is invaluable for debugging a specific daemon. Investigating failed logins? journalctl -u ssh shows every attempt — see protect a VPS from brute-force attacks.

Filter by time

journalctl --since "2026-08-01 00:00" --until "2026-08-01 12:00"
journalctl --since "1 hour ago"
journalctl -u nginx --since today

{{SCREENSHOT}}

Filter by priority

Show only warnings and worse, or only errors:

journalctl -p warning
journalctl -p err -b

Priorities run emerg, alert, crit, err, warning, notice, info, debug. -b limits to the current boot.

Investigate boots and crashes

journalctl -b            # logs since the last boot
journalctl -b -1         # the previous boot (useful after a crash/reboot)
journalctl -k            # kernel messages only (like dmesg)

If the OOM killer struck, journalctl -k | grep -i "out of memory" finds it — a sign you need a swap file or more RAM.

Combine filters

Filters stack, which is where journalctl shines:

journalctl -u nginx -p err --since "2 hours ago"

That's "nginx errors in the last two hours" — exactly what you want when a site starts throwing 500s.

Manage journal size

The journal can grow large. Check its disk usage and prune it:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M      # keep at most 500 MB
sudo journalctl --vacuum-time=2weeks    # keep only the last 2 weeks

Cap it permanently in /etc/systemd/journald.conf:

SystemMaxUse=500M

Then sudo systemctl restart systemd-journald. This ties into freeing up disk space.

Search across fields, not just text

The journal is structured, not just lines of text — every entry carries fields you can filter on precisely. This is far more reliable than grepping. Filter by the process, the executable, or a specific user:

journalctl _SYSTEMD_UNIT=nginx.service _PID=1234
journalctl _COMM=sudo
journalctl _UID=1001

List the available fields for an entry with journalctl -o verbose, then filter on any of them. You can also combine field matches with the time and priority filters above — for example every sudo invocation in the last day at notice level or worse. For scripting, -o json emits one JSON object per line, which pipes cleanly into jq for building reports or shipping structured events elsewhere.

Following a single request or incident

When debugging, the goal is usually to reconstruct one event across services. A reliable workflow: note the timestamp of the symptom, then pull a tight window across everything with journalctl --since/--until, and widen or narrow the priority until the relevant lines surface. Because the journal interleaves all services in true chronological order, you can see the web server, the app, and the kernel side by side at the moment things went wrong — something separate per-service log files make painful. This chronological, cross-service view is journalctl's real superpower, and it's why learning these filters pays off every time production misbehaves.

Make logs persistent

On some systems the journal is stored only in RAM and lost on reboot. To persist it:

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

FAQ

Where are the old /var/log text files?

Many services still write there too, but systemd services log to the journal. Use journalctl for anything managed by systemd; check /var/log for app-specific files.

How do I see logs for just one service?

journalctl -u <service>, e.g. journalctl -u nginx. Add -f to follow live or -e to jump to the newest entries.

Why is my journal empty after reboot?

It's probably stored in volatile memory. Create /var/log/journal and restart journald to make logs persist across reboots.

How do I stop the journal filling my disk?

Set SystemMaxUse in journald.conf, or run journalctl --vacuum-size/--vacuum-time to prune existing logs.

The journalctl commands worth memorising

A small set of invocations covers almost every real debugging session:

• Follow a service live: journalctl -u nginx -f
• Recent errors from a service: journalctl -u myapp -p err -n 100
• A specific time window: journalctl --since "1 hour ago"
• Since the last boot / the previous boot: journalctl -b / journalctl -b -1
• Kernel messages (OOM, hardware): journalctl -k
• Combine filters: journalctl -u nginx -p err --since today
• Check and prune size: journalctl --disk-usage, sudo journalctl --vacuum-size=500M

The mental shift that makes journalctl click is treating it as a structured query tool, not a text file — you filter by unit, priority, time, and field, and the results come back interleaved in true chronological order across every service. That cross-service, time-ordered view is what lets you reconstruct exactly what the machine was doing at the moment something broke, which is precisely what you need when production misbehaves at an inconvenient hour. Spend a few minutes exploring the journal on a healthy server so the filters are muscle memory before you need them under pressure — try following a service live, then narrowing by priority and time. When an incident does hit, that familiarity turns a frantic search into a calm, precise query, and you'll find the relevant lines in seconds rather than scrolling endlessly.

Fluent journalctl turns log spelunking into a quick, precise task. Pair it with live monitoring on a VPS you fully control — see Nxeon VPS hosting.