Something happened last night: where the record actually is

The machine rebooted overnight and nobody asked it to. Everything is running again, nothing is obviously broken, and the only honest statement anyone can make is that something happened.

Monitoring has three records and they answer three different questions. An alert says that something happened. A metric says what shape it had. A log says why. This article is about the third one, and about the awkward fact that the log covering the interesting minute is the one most likely to be gone.

The first question is smaller than you think

Before hardware theories, ask the cheapest question available: was it shut down, or did it die?

One line answers it. A clean shutdown leaves a signature at the end of the previous boot's journal: the logging service records that it was asked to stop, then records that it stopped. A machine that lost power leaves no ending at all. The record simply halts in the middle of ordinary activity.

That single distinction splits the whole investigation in half. A clean ending means something decided to reboot, so look for what asked: an update, a watchdog, a scheduled job, a person. No ending means the machine was interrupted, so look at power, heat, memory and the storage underneath.

But only if the previous boot still exists

Here is the trap. The journal keeps history persistently only when a specific directory exists on disk. When it does not, the journal lives in memory, and every reboot erases exactly the evidence you came looking for. There is no error and no warning; you simply ask for the previous boot and are told there isn't one.

That is worth checking on a quiet afternoon rather than on the morning you need it. It is one directory, and it is the difference between having a record and believing you have one.

It is also the same shape as a trap worth naming twice: a recorder that shares the fate of the thing it records. The graph you want most is the one that stopped being written the moment it got interesting, and the log you want most is from the boot that no longer exists.

The file half the internet tells you to read may not be there

Measured on a current install, Proxmox VE 9.2.6 on Debian 13.6: the classic system logging daemon is not installed, and /var/log/syslog does not exist.

This matters more than it sounds. A large share of the troubleshooting advice written over the past fifteen years opens with "check /var/log/syslog". On a current machine that command returns nothing, and to someone under pressure the result reads as *I have no logs* rather than *I am looking in the wrong place*. The journal is the system record now, and it is queried, not opened in an editor.

Proxmox keeps a second record, and it answers a different question

Separate from the system journal, Proxmox VE keeps its own task log. Every operation started through the web interface or the API becomes a task with an identifier, a start time, an end time and a final status, and there is an index alongside the individual task files. On a single lab host that index held 283 lines with roughly 960 task files behind it.

The two records are good at different things. The journal is good at "what was the system doing". The task log is good at "who asked for what, and did it finish". When a virtual machine has a snapshot nobody remembers taking, or a change appeared without an author, the task log usually answers faster than the journal does, because it is a list of intentions rather than a stream of events.

Decide the ceiling before you need the history

By default the journal's limit is expressed as a share of the filesystem rather than as a length of time. On the host measured above, no explicit limit was set and the journal had grown to roughly 276 MB.

Two numbers are worth knowing in advance: how much space the journal may take, and how far back that actually buys you on this machine. The order matters, and it is the same order that applies to metrics. Decide how far back you need to see, then choose the settings that reach that far. Discovering the answer during an incident means discovering that the answer is "not far enough".

What Atlas does, and does not

Atlas does not replace the journal and does not try to read your logs for you. There is no log search here, and telling you otherwise would set you up for a bad morning.

What Atlas carries is the first half: the daily summary reports an unplanned restart as a fact, with the machine and the time, so the question gets asked at all. The reading is still yours and the journal is still where the answer lives.

That distinction is the whole point. The worst version of last night is not the reboot you investigated with the wrong file open. It is the reboot nobody noticed, because a record no one ever opens answers nothing.