Start with the time and symptom
On Ubuntu 24.04 LTS and AlmaLinux 9, journalctl reads the systemd journal. Use sudo so you can see messages beyond your own account. Begin with a concrete symptom and the approximate time it happened: for example, an SSH login rejected five minutes ago.
Check the server clock before comparing timestamps with your laptop or a monitoring alert. Logs normally show the server's time zone. The --utc option makes journal output easier to compare across systems. These inspection commands do not restart services or remove logs.
date -Is
timedatectl status
sudo journalctl -b -n 50 --no-pagerFilter to the relevant service
The -u option selects a systemd unit, while -b selects the current boot. Ubuntu normally calls OpenSSH ssh.service; AlmaLinux normally uses sshd.service. Substitute the unit for the application you are investigating rather than scanning every message on the server.
If the unit name is uncertain, use systemctl list-units --type=service --all. Not every application writes to the journal: a web server may keep request and error logs in its own configured files.
sudo journalctl -u ssh.service -b -n 100 --no-pagersudo journalctl -u sshd.service -b -n 100 --no-pagerNarrow the time window and priority
Use --since and --until to surround the incident. Relative times work well for a recent problem; explicit timestamps are useful when sharing findings. Avoid filtering too aggressively at first, because an informational line can explain an error that follows.
The priority filter warning includes warning and more severe messages. A clean result means no matching messages were retained, not that every application is healthy. Kernel messages can help with memory pressure, device errors, and network events.
sudo journalctl -b --since "30 minutes ago" -p warning --no-pagersudo journalctl -b --since "30 minutes ago" --until "15 minutes ago" --no-pagersudo journalctl -k -b --no-pagerWatch live activity or inspect an earlier boot
Follow mode displays new entries as they arrive. Reproduce one harmless failed request in another terminal, then press Ctrl+C to stop following. Choose the SSH unit appropriate for your distribution.
List retained boots before requesting the previous one. The -b -1 selection is useful after a reboot, but older entries may be unavailable if the journal was not stored persistently or has rotated. Missing history is a retention question, not a reason to change logging blindly.
sudo journalctl -u sshd.service -fsudo journalctl --list-boots
sudo journalctl -b -1 -p warning --no-pagerSave evidence and check application files
Record a short relevant excerpt with its time zone, unit name, and the command used. Redact tokens, passwords, personal data, and unrelated addresses before sharing it. Correlate several lines around an error rather than treating its severity alone as the diagnosis.
If rsyslog is configured, AlmaLinux commonly stores authentication events in /var/log/secure; Ubuntu commonly uses /var/log/auth.log. Those files may be absent on a minimal installation. Check the application configuration for the authoritative log destination and preserve evidence before changing the service.
sudo journalctl -b --since "15 minutes ago" --utc --no-pagerOfficial documentation
These upstream references provide more detail on the commands and workflows in this guide.