18 September 2026 · One command a day

How do I read a service's logs for the last hour on Linux?

When a service misbehaves, the first question is what it was doing just before things went wrong. On Ubuntu, systemd collects every service's start, stop, reload and crash messages into one journal, and journalctl is how you read it. Adding a time window keeps you looking at the last hour instead of scrolling through weeks of history.

The command

journalctl -u nginx --since "1 hour ago"

journalctl reads the systemd journal. -u nginx restricts the output to one unit, which is systemd's word for a service, so you only see entries logged by or about nginx. --since "1 hour ago" drops everything older than an hour. The quotes matter because the value contains spaces. If the output ends with a hint that you are not seeing messages from other users, your account is not in the adm or systemd-journal group, so run it again with sudo in front.

What you will see

Sep 18 09:14:02 host systemd[1]: Starting nginx.service - A high performance web server and a reverse proxy server...
Sep 18 09:14:02 host systemd[1]: Started nginx.service - A high performance web server and a reverse proxy server.
Sep 18 09:41:15 host nginx[21874]: 2026/09/18 09:41:15 [emerg] 21874#21874: unexpected "}" in /etc/nginx/sites-enabled/example.com:12
Sep 18 09:41:15 host systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Sep 18 09:41:15 host systemd[1]: Reload failed for nginx.service - A high performance web server and a reverse proxy server.

Each line starts with a timestamp, the hostname, then the program that wrote the message and its process ID in square brackets. Lines from systemd[1] describe what the service manager did: starting, stopping, reloading or reporting a failure. Lines from nginx[...] are nginx's own messages. In the example, a reload at 09:41 failed because a site file has a stray brace on line 12, and the running nginx kept serving with the old config. Running a config test before reloading catches this before it reaches the log. If nothing is printed, nginx logged nothing in that hour, which is usually good news.

When to use it

• A site is down and you want to know whether nginx stopped, crashed or was restarted, and at what time.
• You ran a deploy or edited a config in the last hour and want to confirm the reload went through cleanly.
• Something odd happened overnight and you want the log for a fixed window, swapping "1 hour ago" for a time such as "03:00".

Watch out for

The journal is not the access log. nginx on Ubuntu writes requests and most runtime errors to files under /var/log/nginx, and only its startup, shutdown and reload messages reach the journal. So if you are hunting for a 502 or a slow request, this command will show you nothing useful. It tells you what happened to the service, not what happened to each visitor. For request errors, watch the nginx error log instead.

Questions people ask

Does this work for services other than nginx?

Yes. Any service managed by systemd works the same way, so journalctl -u docker --since "1 hour ago" or -u ssh reads those logs instead. Run systemctl list-units --type=service to see the names.

Can I pick a different time window?

Yes. --since accepts phrases like "30 min ago", "yesterday" and "today", or a full timestamp such as "2026-09-18 09:00". Add --until with the same formats to set the other end of the window.

Reading a service's log for exactly the hour you care about is a small thing, but it is only possible on a server you control, where systemd runs and you have shell access. You can get the same VPS with 20% off at https://asksteves.co.uk/vps. Affiliate link.