Proxmox Hypervisor restarts itself and you have no idea why? Start with the logs and the hardware watchdog — that’s where the answer is hiding 90% of the time. Don’t go swapping RAM sticks until you’ve done this.

Check the damn logs first
Before you touch any hardware, look at what the system recorded. The journal has timestamps right up to the crash, and that’s usually enough to point you at the real cause.
journalctl -b -1 -e
That shows the end of the previous boot’s log. You’re looking for anything that screams “panic”, “watchdog”, “temperature”, or “oom”. If you see a kernel panic, note the call trace — it tells you which module or driver blew up.
Also check the syslog:
less /var/log/syslog
Scroll near the time of the reboot. If there’s a thermal shutdown, you’ll see it there. No logs at all? That’s a clue — probably a sudden power loss or a hardware reset that didn’t give the OS time to write anything.
The watchdog is a silent killer
Proxmox ships with a hardware watchdog enabled by default. If the host hangs for more than 60 seconds, the watchdog fires and reboots the box. It won’t leave a friendly note — just a clean reboot in the logs and a lot of confusion.
Check if it’s active:
systemctl status watchdog-mux.service
If it’s running, disable it temporarily to see if the reboots stop:
systemctl stop watchdog-mux.service
systemctl disable watchdog-mux.service
I’d do this before anything else. If the random reboots vanish, you know it’s not hardware — it’s something causing the host to freeze long enough for the watchdog to kick in. Could be a storage hang, a bad kernel update, or a VM doing something stupid. Check dmesg for I/O errors or hung tasks.

Hardware checks — but only after the easy stuff
If the logs are clean and the watchdog wasn’t the culprit, then yeah, it’s probably hardware. But don’t just guess. Run a memory test overnight — Proxmox has Memtest86+ in the boot menu. For CPU stability, stress it with stress-ng and watch the temperatures with sensors.
Power supply issues are trickier. If the reboot happens under heavy load, a failing PSU is a real possibility. No log will tell you that — you just have to swap it and see.
My take
Most of the time, it’s the watchdog or a kernel panic you can actually fix. Don’t be the person who reseats every cable before reading journalctl. If you’ve got a backup host, check the evidence checklist after a kernel update — same diagnostic mindset applies here. And if you’re running a two-node cluster, watch out for VM stalls when rebooting an adjacent node — that can look like a host problem when it’s really a cluster quorum issue.