The Linux Command That Shows You What Your Computer Was Doing Before It Crashed

The system records everything leading up to a crash. Here is how to read that record

Photo by Ishaq Robin on Unsplash

Your computer crashed. Maybe it froze and you held the power button. Maybe the screen went black. Maybe it rebooted by itself with no warning.

Now it’s back up. Everything looks normal. But something went wrong and you don’t know what, or whether it will happen again.

The good news is your system was recording everything right up until the moment it went down. That record survives the crash and is readable the moment the system comes back up.

Here is exactly how to read it.

The first command to run after a crash

journalctl -b -1

The -b flag filters by boot. -1 means the previous boot, the one that ended in the crash. This shows everything the system logged during that session, from startup to the last entry before it went down.

The output is long. Start at the end, which is where the crash happened.

journalctl -b -1 -e

The -e flag jumps to the end of the log immediately. The last few dozen lines before the crash contain the most relevant information.

If you want to see only errors and critical messages from that boot:

journalctl -b -1 -p err

This filters to log entries at error priority and above, cutting out the noise and leaving you with the lines most likely to explain what happened.

List all recorded boots

To see every boot the system has recorded:

journalctl --list-boots

The output looks like this:

-3 a1b2c3d4e5f6 Thu 2026-06-24 08:12:31 WAT—Thu 2026-06-24 22:45:10 WAT
-2 b2c3d4e5f6a1 Fri 2026-06-25 09:00:14 WAT—Fri 2026-06-25 18:30:22 WAT
-1 c3d4e5f6a1b2 Sat 2026-06-26 10:15:00 WAT—Sat 2026-06-26 14:22:41 WAT
 0 d4e5f6a1b2c3 Sun 2026-06-27 08:00:05 WAT—still running

Negative numbers count back from the current boot. 0 is now. -1 is last time. -2 is the one before that.

A boot that ended abruptly with no clean shutdown timestamp is a crash. If the end time shows only a start time and nothing after, the system didn’t shut down gracefully.

The kernel ring buffer: what the hardware saw

The kernel keeps its own log called the ring buffer. It records low-level hardware events, driver messages, and kernel warnings that don’t always make it into the systemd journal.

dmesg

This prints the entire kernel ring buffer from the current boot. For post-crash investigation, look at the kernel messages from the previous boot using journalctl with the -k flag.

journalctl -b -1 -k

The -k flag limits output to kernel messages only. Look for lines containing words like panic, oom, killed, error, fault, hung, or timeout.

A kernel panic looks like this in the log:

kernel: Kernel panic - not syncing: hung_task: blocked tasks

An out-of-memory kill looks like this:

kernel: Out of memory: Killed process 4821 (chrome) total-vm:8GB, anon-rss:4GB

Both of these are clear signals of what happened. The kernel panic tells you the system detected an unrecoverable error. The OOM kill tells you the system ran out of memory and started terminating processes to survive, which sometimes doesn’t work and the system goes down anyway.

Common crash causes and what they look like in the log

Out of memory (OOM)

The OOM killer appears in the log when memory runs out. It starts killing processes starting with the ones using the most memory. If it can’t free enough, the system may crash.

journalctl -b -1 | grep -i "out of memory"
journalctl -b -1 | grep -i "oom"

Kernel panic

A kernel panic is a fatal error the kernel cannot recover from. It’s the Linux equivalent of a blue screen.

journalctl -b -1 | grep -i "panic"

Hardware errors

Storage failures, memory errors, and overheating all leave traces in the kernel log.

journalctl -b -1 -k | grep -i "error"
journalctl -b -1 -k | grep -i "temperature"

A process that hung the system

journalctl -b -1 | grep -i "hung_task"

A hung task is a process that has been stuck waiting for something, usually a disk operation, for longer than the kernel’s timeout threshold. On a busy or failing disk this is common.

Check the system’s uptime and last reboot time

last reboot | head -10

This shows the last ten reboot events with timestamps. A reboot at an unusual time when you weren’t at the machine, or a reboot with no matching logout from your user session, suggests an unplanned crash rather than a deliberate restart.

Check for disk errors that may have caused instability

A failing disk causes all kinds of system instability before it finally fails completely. The kernel logs errors every time a disk operation fails or retries.

journalctl -b -1 -k | grep -i "I/O error"
journalctl -b -1 -k | grep -i "blk_update_request"

Multiple I/O errors in a short window before a crash is a strong indicator the disk is failing. Back up everything immediately if you see this.

What to do when the log shows nothing useful

Some crashes are too sudden for the system to log them. A power cut, a hardware failure that takes the system down before the kernel can write anything, or a kernel panic so severe it can’t flush its buffer to disk will leave no trace in the journal.

In those cases, check the hardware directly.

sudo smartctl -a /dev/sda

smartctl reads the disk's own internal health log. Replace /dev/sda with your actual disk device, which you can find with lsblk. A disk reporting reallocated sectors, pending sectors, or uncorrectable errors is a disk in the process of failing.

For memory, a bad RAM module causes crashes that look random and leave confusing log entries. The only reliable test is memtest86, a tool that runs before the operating system loads and tests every byte of RAM directly.

The habit worth building

Running journalctl -b -1 -e takes thirty seconds after an unexpected reboot. It takes ten seconds if you know what you're looking for.

The log doesn’t always have a clean explanation. Crashes are sometimes messy and the record reflects that. But checking after every unexpected shutdown builds a picture over time, and patterns in that picture tell you when a component is starting to fail before it fails completely.

I have opened a terminal a hundred times and still felt lost inside it. Commands I copy from somewhere and forget by the next day. Errors that mean nothing until something breaks. No feedback telling me why. Terminal Academy puts you inside your own real terminal and lets you break things safely, then tells you exactly why. Start free at **Terminal Academy →**