By Greg Nowak. Last updated 2026-09-07.
When a website stops responding or a scheduled job fails, Ubuntu’s logs can help you work out what happened. The challenge is finding the relevant messages and connecting them to the business problem: missed orders, delayed work, or an unavailable service.
journalctl and dmesg are useful starting points. This guide gives you a practical sequence for investigating an Ubuntu server and collecting evidence that a developer, hosting provider, or operations team can act on.
Which log should you check first?
journalctl reads the systemd journal, including service and kernel messages collected there. dmesg reads the kernel’s ring buffer, which is useful for investigating hardware, drivers, storage, and memory problems.
| What you are investigating | Start with | What to look for |
|---|---|---|
| A service that stopped or failed to start | journalctl filtered by service | The first failure and messages immediately before it |
| A disk, driver, or network interface problem | dmesg or journalctl -k | Device errors, resets, or link changes |
| A problem before a reboot | journalctl with a previous boot selected | The sequence leading up to the interruption |
| A failed page request or application task | Service journal, then application logs | The matching request, exception, or job identifier |
Application details may be written to separate files or a container logging system. An empty journal search does not establish that the application is healthy.
Start with the time the problem happened
Before opening a terminal, note the affected system, the symptom, the approximate start time, and any recent deployment or configuration change. “Checkout failed at 09:15 UTC” gives everyone a better starting point than “the server was slow this morning.”
These commands retain the original article’s useful time filters. Use an account authorised to administer the server; sudo provides access to system logs that your normal account may not see.
sudo journalctl --since "1 day ago"
sudo journalctl --since "10 hours ago"“1 day ago” means a rolling 24-hour window. “Yesterday” starts at midnight yesterday. For a repeatable investigation, use explicit dates and a timezone, following the systemd time syntax:
sudo journalctl --since "2026-09-07 09:00:00 UTC" --until "2026-09-07 09:30:00 UTC" --utc --no-pagerReplace those example times with your incident window. Include a few minutes before the first reported failure: the visible symptom may follow the underlying problem.
Find errors, then read the surrounding context
sudo journalctl --since "12 hours ago" -p 3 -x --utc --no-pager-p 3 selects errors and more severe messages. -x adds explanations where available; --utc displays UTC timestamps; --no-pager prints directly to the terminal. The journalctl manual recommends omitting -x from bug-report attachments.
Treat this as a first pass. Once you find a relevant error, repeat the search over a smaller window without the priority filter. Warnings and ordinary messages may explain what led to the failure. A severe message elsewhere on the machine may be unrelated.
Focus on the affected service
For a service-specific investigation, replace nginx.service below with the actual systemd unit name:
sudo journalctl -u nginx.service --since "1 hour ago"
sudo journalctl -u nginx.service -n 50 -fThe second command shows the latest 50 entries, then follows new messages. Press Ctrl+C to stop.
Use this while reproducing a safe test request or checking an agreed fix. Note the test time, change one thing at a time, and confirm that the affected business function works again. A successful service start alone does not prove that a customer can complete their task.
Use dmesg for kernel clues
sudo dmesg | less
sudo dmesg -H --time-format isoBoth commands let you browse kernel messages. The second keeps the original readable timestamp approach, but removes the extra pipe: -H already enables a pager. Press q to exit.
Look for messages near the failure involving storage I/O, device resets, or processes killed because memory ran out. These are clues to investigate, not a diagnosis by themselves.
The Ubuntu dmesg manual notes that ISO timestamps can be inaccurate after suspend and resume. Access may also be restricted; a permission error does not mean the buffer is empty.
Check what survived a reboot
sudo journalctl --list-boots
sudo journalctl -b -1
sudo journalctl -k -b -1These list retained boots, show the previous boot, and narrow that boot to kernel messages. They require the relevant journal data to still exist.
If it is missing, review retention and storage configuration. Storage=volatile keeps journal data in memory; Storage=persistent prefers disk storage. With Storage=auto, the presence of /var/log/journal determines the behaviour. Check the installed configuration rather than assuming a default across Ubuntu releases. The journald configuration manual explains these settings and storage limits.
Give the next person a useful handover
Share the affected service, incident times and timezone, relevant log excerpt, recent changes, and what you tested. Remove credentials and customer information before sharing. Keep enough surrounding lines to preserve the sequence.
If recurring Ubuntu problems are interrupting delivery, I can help turn the investigation into a clear plan with your developers or hosting provider. Contact Greg with the symptoms, your setup, and where your team is getting stuck.
Related on GrN.dk
- Drupal 7 HTTPRL Network Errors: A Practical Fix and Triage Guide
- NGINX 1.30 changed upstream connection reuse: what to check before you upgrade
- When Google can call the business, your local data stops being cosmetic
Need help with this kind of work?
Discuss your Ubuntu server issue with Greg Get in touch with Greg.
