How to Read journalctl Logs to Find Why Your Server Rebooted

You come in, try to open your Ubuntu server’s dashboard, and find that it rebooted in the middle of the night. It is running fine now, nobody was in the building, and there is no note explaining what happened. Was it a power cut, a kernel crash, an automatic update, or someone running a command? The answer is almost always recorded in the system journal. This guide teaches you a calm, repeatable way to use journalctl to find why an Ubuntu server rebooted overnight.

Quick Answer

List recent boots with journalctl --list-boots, then read the end of the previous boot with journalctl -b -1 -e and the start of the current boot with journalctl -b 0. Look for clean shutdown messages, update and reboot notices, kernel panic or out-of-memory errors, and power loss clues such as a journal that stops suddenly with no shutdown lines at all.

Where Ubuntu Records a Reboot

Ubuntu uses systemd, which keeps a central log called the journal. Services, the kernel, login events, and shutdown steps all write into it, and the command to read it is journalctl. On a server the journal is usually persistent, meaning logs survive a reboot and are stored under /var/log/journal/. That persistence makes overnight detective work possible.

Each boot gets a number. The current boot is 0, the one before it is -1, then -2, and so on. Reading the last minutes of boot -1 is the most useful habit in this guide, because a clean shutdown writes clear closing lines, a crash writes errors, and a power cut writes nothing at all. The absence of lines is itself evidence. You will normally need sudo journalctl to see everything.

Step 1: Confirm When the Reboot Happened

1. Show uptime and the current boot time with uptime and who -b. The who output gives you the system boot date and time.
2. List all recorded boots with journalctl --list-boots. Note the start and end times for the current boot and the previous boot.
3. For a quick recent history of logins, reboots, and shutdowns, run last -x | head -30. It shows reboot and shutdown events in plain language.
4. Note the exact gap. If the previous boot ended at 02:13 and the new boot began at 02:14, the machine rebooted immediately. If the new boot began at 06:40, it was off or down for hours, which points more towards power or hardware.
5. Keep those times written down. Every later search should focus on the thirty minutes before the old boot ended.

If --list-boots shows only the current boot, persistent logging may be off. Our broader guide on how to use journalctl to view and filter Linux logs is a useful companion for general filtering commands.

Step 2: Read the End of the Previous Boot

This is the heart of the investigation. You want the last lines the system wrote before it stopped.

1. Open the previous boot at its end with sudo journalctl -b -1 -e. The -e flag jumps straight to the newest entries of that boot.
2. Page upwards slowly through the last few minutes. Look for words like shutting down, reboot target, powering off, or stopped target.
3. If it is easier to save and search, export that window with sudo journalctl -b -1 --since "2026-10-20 02:00" --until "2026-10-20 02:20", using times around your event.
4. Search that boot for reboot and shutdown mentions with sudo journalctl -b -1 | grep -i -E "reboot|shutdown|power".
5. Note the very last timestamp and the last service or kernel line before silence.

Signs of a clean, planned reboot

A clean reboot leaves an orderly trail: a message that a reboot was requested, services stopping one by one, file systems being unmounted, and a line about reaching the reboot target. If you see that trail after an update tool ran, or after a logged-in user ran a reboot command, it was a planned restart, not a fault.

Signs of a power cut or hard crash

If the journal simply stops, with normal activity one minute and no shutdown sequence at all, the machine likely lost power or froze completely. At the start of the next boot, you may also see file system recovery messages, which support the sudden-loss theory.

The official options are documented on the journalctl man page on man7.org, and in the Ubuntu Server guide to system logging.

Step 3: Read the Start of the Current Boot for Clues

1. Read the beginning of this boot with sudo journalctl -b 0 and page through the first minutes.
2. Look for kernel messages about recovering a journal, cleaning orphaned inodes, or file system checks, which suggest the previous shutdown was not clean.
3. Search for serious early errors with sudo journalctl -b 0 -p err, which shows messages at error priority and above.
4. Check the kernel ring messages for this boot with sudo journalctl -b 0 -k | head -100 if you suspect hardware or driver trouble.
5. Compare the boot time here with the list-boots output to confirm you are investigating the right event.

Step 4: Check the Four Most Common Overnight Causes

1. Automatic updates and a required restart

Ubuntu servers often install security updates automatically through unattended-upgrades, and some need a reboot. Search with sudo journalctl -b -1 | grep -i unattended and review recent entries in /var/log/apt/history.log. If a kernel update installed at 02:00 and a clean reboot followed, you have your answer.

2. Kernel panic, watchdog, or out-of-memory kill

Search the previous boot with sudo journalctl -b -1 -k | grep -i -E "panic|watchdog|oom|out of memory". An out-of-memory event does not normally reboot the machine by itself, but repeated memory pressure plus a watchdog can. A true panic may leave the machine frozen until a watchdog or a person restarts it, which matches a long gap before the next boot.

3. A person or a script ran the reboot

Look for login and sudo evidence with sudo journalctl -b -1 | grep -i -E "sudo|session opened" and cross-check last -x. Scheduled tasks can also do it, so review systemd timers with systemctl list-timers --all. A forgotten maintenance timer is a common overnight culprit.

4. Hardware, heat, and power problems

If there is no shutdown trail, no update, and no human action, treat hardware seriously. Look for disk or temperature errors with sudo journalctl -b -1 -k | grep -i -E "error|fail|temperature", and ask about building power at that time.

Step 5: Make the Next Investigation Easier

• Confirm persistent logging is on by checking that /var/log/journal/ exists and is growing. If it is missing, set Storage=persistent in /etc/systemd/journald.conf and restart the journal service with care.
• Check journal disk use with journalctl --disk-usage, so you know logs are not being deleted too quickly on a small disk.
• Keep server time accurate with an NTP service, because wrong timestamps make overnight timelines useless.
• Add simple uptime monitoring that alerts you when a boot happens, so you investigate the same morning, while logs and memories are fresh.
• Write a one-line note after each planned reboot, with the date, reason, and who did it. Ten seconds of notes can save an hour of log reading later.

Common Mistakes and Useful Tips

• Only reading the current boot: The cause of a reboot lives at the end of the previous boot. -b -1 should be your first move, not your last.
• Searching the whole journal with no time window: You will drown in output. Use –since and –until around the known reboot time.
• Taking sudden silence as no evidence: A journal that stops with no shutdown lines is strong evidence of power loss or a hard freeze. Note it and check power.
• Forgetting updates: Always check the apt history and unattended-upgrades before assuming a fault. Planned restarts after kernel updates are normal.
• Ignoring the human world: Cleaners, timers, building power work, and colleagues in other time zones reboot servers too. Logs plus one question often solves it fastest.
• Tip — save your evidence: Export the key window to a file with sudo journalctl -b -1 > reboot-evidence.txt before logs rotate away.
• Tip — learn the priority filter: -p err and -p warning cut thousands of normal lines down to the ones that matter.

Conclusion

To find why your Ubuntu server rebooted overnight, start with journalctl --list-boots to pin down the time, read the end of the previous boot with journalctl -b -1 -e for a shutdown trail, an update trail, errors, or sudden silence, then check the start of the current boot for recovery clues. Test the four usual causes in order: automatic updates, kernel or memory trouble, a person or timer, and power or hardware. Keep persistent logs and simple notes, and the next overnight reboot will take minutes, not a morning, to explain.

Frequently Asked Questions

What is the first journalctl command I should run after an unexpected reboot?

Run journalctl --list-boots to confirm the boot times, then sudo journalctl -b -1 -e to read the last entries before the machine stopped. Those two commands give you the timeline and the most important evidence in under a minute.

How can I tell a power cut from a normal reboot in the logs?

A normal reboot has an orderly shutdown sequence with services stopping and a reboot target message. A power cut has no shutdown sequence at all: normal activity, then silence, then a new boot that may show file system recovery messages at its start.

Why does journalctl only show the current boot on my server?

Your journal is probably not persistent, or its storage is limited and old boots were removed. Check for /var/log/journal/, review the Storage setting in journald.conf, and check disk usage with journalctl --disk-usage.

Can journalctl tell me if an automatic update rebooted the server?

Indirectly, yes. Look in the previous boot for unattended-upgrades activity, then check /var/log/apt/history.log for a kernel or system update at the same time, followed by a clean shutdown trail. That matching timing is strong evidence of a planned update reboot.