On a modern Linux box, journalctl is where the answers live — systemd captures the logs of every service into one queryable journal. The trick isn't knowing the command exists; it's knowing the handful of flags that turn a wall of text into the one line that explains the outage.
Filter to one service
Start narrow. journalctl -u nginx shows only that unit's logs. Add -e to jump to the end (most recent), or -n 50 for the last 50 lines.
Follow it live
journalctl -u nginx -f tails the journal in real time — the equivalent of tail -f — so you can watch what a service does the moment you restart it or send it traffic.
Scope to a time window
When you know roughly when it broke, slice by time: journalctl --since "10 min ago" or journalctl --since "2026-06-13 14:00" --until "14:15". This is the fastest way to cut a noisy journal down to the incident.
Show only what hurts
journalctl -p err -b shows error-priority (and worse) messages from the current boot — -b means "this boot", and -b -1 the previous one, which is how you investigate a box that just rebooted. Combine freely: journalctl -u myapp -p err --since "1 hour ago".
Find the OOM kill and other smoking guns
A service that vanished without logging an error was often killed from outside it. Add -k (kernel messages) and grep — an out-of-memory kill shows up there. Pair journalctl with systemctl status <unit> to see the exit code next to the logs that explain it.
Build the reflex
Reading logs under pressure is a skill you drill, not memorise. Practise it on live, broken boxes with Linux troubleshooting and a full incident response shift.