Droplet Unreachable After Reboot — Fix Steps

The Short Version (30 Seconds)

Before you dig into anything heavy, check this first. I've seen people waste an hour on kernel panics when the fix was literally one click.

1. Log into the DigitalOcean control panel — not via SSH, through the web browser.
2. Go to your droplet's page. Look for the "Recovery Console" button (top right corner of the droplet detail page). It looks like a monitor icon.
3. Click it. This opens a browser-based terminal that connects directly to your droplet's serial console. No network needed.
4. Wait 10-15 seconds. You should see a login prompt. Log in with your regular username and password (or SSH key if you set it up for console access).

If you get a prompt, you're in. The issue is almost certainly network config — your SSH daemon is running, but the network stack didn't come up properly after reboot. Skip to the moderate fix.

If the console shows nothing but a blank screen or a blinking cursor, your droplet didn't finish booting. That's a different problem — move to the advanced fix.

The Moderate Fix (5 Minutes) — Network Came Up Wrong

What's actually happening here is that DigitalOcean droplets use cloud-init to configure networking on first boot. After a reboot, cloud-init runs again, and sometimes it gets confused. The network interface comes up but with the wrong IP or no default gateway.

Real-world trigger: You rebooted after a distro upgrade (like Ubuntu 20.04 to 22.04) or after you manually edited /etc/network/interfaces or /etc/netplan/*.yaml. That often breaks cloud-init's setup.

Step 1: Check network config inside the recovery console

ip addr show
ip route show default

Look for your public IP. If you see an IP that starts with 10. or 192.168., that's a private internal IP — DigitalOcean gives droplets both a public and private IP. Your public IP should match the one shown in the control panel. If it's missing, that's the problem.

Step 2: Force cloud-init to reconfigure networking

sudo cloud-init clean --configs network
sudo reboot

The --configs network flag tells cloud-init to wipe its cached network config and re-run the whole setup on next boot. The reason this works is that cloud-init keeps a state file in /var/lib/cloud/instance. If that file says "network is done", it won't reapply the config even if it's broken. Cleaning it forces a fresh run.

After the reboot (give it 2-3 minutes), try SSH again. If it works, you're done. If not, move to the next step.

Step 3: Manually bring up the network (temporary fix)

sudo dhclient eth0
sudo systemctl restart sshd

Replace eth0 with whatever your interface is — check with ip link show. On newer Ubuntu/Debian it's often ens3 or ens4. This grabs a fresh DHCP lease and restarts SSH. If this works but the reboot fix didn't, you have a persistent config issue. You'll need to set a static config or fix cloud-init properly (see advanced).

The Advanced Fix (15+ Minutes) — Kernel Panic or Boot Failure

If the recovery console shows nothing, or you see messages like Kernel panic - not syncing, the droplet didn't finish booting. This happens after a kernel update that went wrong, or a corrupted initramfs.

Step 1: Reboot into recovery mode

In the DigitalOcean control panel, click on your droplet, then go to Settings > Rescue. Enable the recovery ISO. This boots the droplet from a minimal Linux environment on DigitalOcean's side. Wait 2-3 minutes, then use the recovery console to log in as root with the password shown in the panel.

You're now in a rescue environment. Your droplet's disk is mounted at /mnt. You can chroot into it:

chroot /mnt /bin/bash

This runs commands inside your droplet's filesystem, not the rescue OS.

Step 2: Fix the bootloader or kernel

Check what kernels are installed:

dpkg --list | grep linux-image
 # or for RHEL/CentOS:
 rpm -qa | grep kernel

If you see multiple versions, the newest one might be broken. Remove it and reinstall:

apt-get remove --purge linux-image-5.15.0-86-generic
update-grub
apt-get install --reinstall linux-image-generic
update-grub

Replace the version with whatever you see. The reason update-grub is important: it rebuilds the bootloader config. Without it, GRUB still points to the missing kernel and the droplet panics on boot.

Step 3: Rebuild initramfs

Sometimes the initramfs (initial RAM filesystem) is corrupted. That's what loads drivers before the real root filesystem mounts. Rebuild it:

update-initramfs -u -k all

If that fails, force a rebuild:

mkinitramfs -o /boot/initrd.img-$(uname -r) $(uname -r)

Step 4: Exit and reboot

exit   # exits chroot
reboot

Disable the recovery ISO in the control panel (same place you enabled it). Then reboot the droplet. Wait 3-5 minutes — kernels rebuilds can take time on low-RAM droplets.

If you still can't reach it after this, it's a hardware issue. Contact DigitalOcean support. They can move your droplet to a different host node. I've seen that fix stubborn cases where nothing else worked.

Quick Reference Table

One last thing: if you're on a 512MB RAM droplet (the $5/month one), it's easy to run out of memory during boot if you have too many services enabled. That looks like a boot failure but is really an OOM (out of memory) kill. The fix is to add a swap file after you get in via recovery:

dd if=/dev/zero of=/swapfile bs=1M count=1024
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

That gives you an extra 1GB of swap. It's slow, but it'll prevent the OOM killer from taking down SSH during boot.