VPS keeps rebooting: find out why and stop the restart loop

A server that restarts on its own is either being told to reboot — by a scheduled job, automatic updates or a service — or it is crashing: kernel panic, watchdog, or a reset on the host. The evidence and the fix are different for each, so the first job is to find out which one you have. Do it before the next restart wipes whatever is on the screen.

1. When did it reboot, and how did it go down?

journalctl --list-boots | tail -10     # one line per boot, with start and end times
uptime -s                              # when the current boot started
last -x | grep -E 'reboot|shutdown' | head -20

On Debian 13 the last command comes from the wtmpdb package. If it is missing, the journal is enough.

Now read the final lines the previous boot wrote before it went down:

journalctl -b -1 -n 60 --no-pager

• It ends with an orderly shutdown — services stopping, Reached target … Reboot, Journal stopped. Something asked for the reboot. Go to scheduled and automatic reboots.
• It just stops in the middle of normal messages. The machine went down without shutting down: a kernel panic, a watchdog, or a reset on the host.

2. Scheduled and automatic reboots

A clean reboot at the same time every night is almost always configured somewhere:

# unattended-upgrades rebooting after kernel updates
grep -r "Automatic-Reboot" /etc/apt/apt.conf.d/

# cron jobs and systemd timers
sudo grep -rE "reboot|shutdown" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null
systemctl list-timers --all

# someone running it by hand
sudo journalctl -b -1 | grep -iE "system is rebooting|COMMAND=.*(reboot|shutdown)"

Unattended-Upgrade::Automatic-Reboot “true” is a deliberate choice on many servers: it applies kernel security fixes. Keep it if you want that, and set Automatic-Reboot-Time to a quiet hour. On RHEL-family systems, look for a reboot setting in /etc/dnf/automatic.conf.

systemd units can also reboot the machine when they fail. Check for them:

grep -rE "^(FailureAction|SuccessAction|StartLimitAction)=reboot|^OnFailure=reboot" \
  /etc/systemd /usr/lib/systemd /lib/systemd 2>/dev/null

3. Kernel panics

A panic is an error the kernel cannot recover from. Whether the machine then reboots or stays frozen depends on kernel.panic. Many images set it to a few seconds, so a panic looks like a spontaneous reboot.

journalctl -k -b -1 | grep -iE "panic|oops|bug:|call trace|soft lockup|hung_task"
sysctl kernel.panic kernel.panic_on_oops vm.panic_on_oom

The panic message itself often never reaches the disk. The reliable way to catch it is to keep the provider’s VNC console open, and to set kernel.panic = 0 temporarily so the message stays on screen instead of vanishing into a reboot. Put automatic reboot back once you know the cause. On a production box it is what brings the server back unattended.

It started after a kernel update

This is the most common trigger. Boot the previous kernel from the GRUB menu: open the VNC console, reboot, hold Shift (BIOS) or tap Esc (UEFI), then choose Advanced options and the older kernel. Once it is up:

uname -r                                  # the kernel that works
sudo apt remove linux-image-<broken-version>
# stop the next update pulling it back in, until a fixed release is out
sudo apt-mark hold linux-image-amd64      # Debian
sudo apt-mark hold linux-image-generic    # Ubuntu

sudo grubby --set-default /boot/vmlinuz-<working-version>

Remove the hold (apt-mark unhold) once a newer kernel is out, or you stop receiving kernel security fixes.

For panics you cannot explain, kdump saves a crash dump to /var/crash for analysis (kdump-tools on Debian and Ubuntu, kexec-tools on RHEL). It reserves RAM for a second kernel, which hurts on a small VPS, so enable it while you investigate and turn it off afterwards.

4. Out of memory — a crash that is not a reboot

The OOM killer does not restart the server. It kills the biggest process to free memory. But when that process is your database or web server, and SSH drops too, it looks exactly like a reboot from outside. uptime tells you which one happened.

journalctl -k | grep -iE "out of memory|oom-kill|killed process"
free -h

The only way OOM does reboot a machine is vm.panic_on_oom = 1 combined with a non-zero kernel.panic. The real fix is to lower memory settings (MySQL buffer pool, PHP-FPM pm.max_children, JVM heap) or add RAM. A small swap file absorbs spikes:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

5. Watchdogs

A watchdog reboots the machine when the system stops responding: the kernel, systemd or the watchdog daemon failed to check in in time. It is working as designed. The real question is why the system hung — usually memory exhaustion and heavy swapping, or storage that stopped answering.

ls /dev/watchdog* 2>/dev/null
grep -E "^(RuntimeWatchdogSec|RebootWatchdogSec)" /etc/systemd/system.conf /etc/systemd/system.conf.d/*.conf 2>/dev/null
systemctl status watchdog 2>/dev/null
sysctl kernel.softlockup_panic kernel.hung_task_panic

6. It never finishes booting

If the server restarts during boot, only the VNC console shows you where. Two common causes:

• Filesystem errors. Boot the rescue system from the panel and check the root filesystem while it is not mounted. lsblk -f shows which partition it is; run fsck -f /dev/vda1 for ext4 or xfs_repair /dev/vda1 for XFS.
• A broken initramfs after an interrupted update. Boot an older kernel as above, then rebuild it with sudo update-initramfs -u -k all (Debian, Ubuntu) or sudo dracut -f --regenerate-all (RHEL family).

7. None of the above: the host

Logs that stop mid-sentence, repeatedly, with no panic, no OOM and no watchdog, point below your VM: host maintenance, a host crash, or a hardware fault on the node. Only the provider can see that. Open a ticket and include:

• the exact times of each reboot, in UTC (journalctl --list-boots),
• the last lines of the previous boot (journalctl -b -1 -n 80 --no-pager), and
• anything you saw on the console while it restarted.

With that, support can match your timestamps against the host’s event log in minutes instead of guessing. Every VMHeaven KVM VPS has a VNC console and a rescue system in the panel, which are the two tools most of the steps above depend on.

Frequently asked