My website didn't come back after a reboot or unsuspension

What this is#

Your VPS is up, it pings, SSH works, but the website, app, or database on it is offline. This almost always follows a power cycle, and the most common script goes: an invoice went overdue, the VPS was suspended, you paid, it reactivated automatically, and it booted fresh, without your services.

Here's the trap: starting a service and enabling it are two different things. systemctl start nginx runs it now; systemctl enable nginx registers it to run at every boot. A service started by hand during setup runs happily for months, and evaporates at the first power cycle, suspension/reactivation, a traffic-overage suspension, your own reboot, all the same. Nothing was lost and nothing is broken: the software just wasn't told to rise with the machine.

Diagnose it in one minute#

SSH in and ask systemd about the services your site depends on:

systemctl status nginx mariadb php8.2-fpm

The smoking gun is in each output's first lines: Active: inactive (dead) combined with Loaded: ... ; disabled;. Inactive plus disabled after a reboot is this exact problem. To see every disabled unit at once:

systemctl list-unit-files --state=disabled

Fix it now, and forever#

One command does both, per service:

systemctl enable --now nginx mariadb php8.2-fpm

--now starts it immediately; enable makes it boot-persistent. Walk your whole stack, web server, database, PHP-FPM or your app service, cache (Redis), queue workers, and confirm each: systemctl is-enabled nginx should say enabled.

If a service starts but the site still misbehaves, work the 502/503 guide, and if a service refuses to start, read its own last words: journalctl -u mariadb -n 50. (A database that won't start right after a suspension period is occasionally a full disk, the ten-second df -h is always worth it.)

Docker: containers need a restart policy#

Containers don't participate in systemd, they come back only if Docker is told to bring them back:

• Fix existing containers: docker update --restart unless-stopped <container> (repeat per container, or all at once: docker update --restart unless-stopped $(docker ps -aq)).
• In compose files: restart: unless-stopped on each service.
• And confirm the Docker daemon itself is enabled: systemctl is-enabled docker.

unless-stopped is usually the right policy: it survives reboots but respects containers you deliberately stopped.

Apps running in screen, tmux, or nohup#

Anything you launched in a screen/tmux session or with nohup does not survive a reboot, those are conveniences for your login session, not service managers. Give the app a real home:

• A systemd unit is ten lines and does everything: starts at boot, restarts on crash (Restart=always), logs to journald. Any AI chatbot drafts one correctly from "write a systemd service for running as in ".
• Node.js crowd: pm2 works too, pm2 startup + pm2 save is its boot-persistence step, which people forget exactly the same way.

Verify like you mean it#

The only real test of "everything starts on boot" is a boot. At a calm moment:

reboot

Give it a minute, then check the site, and systemctl --failed for anything that didn't make it. Two minutes of planned downtime now beats rediscovering this page after the next suspension.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• which services are down, with their systemctl status output,
• what preceded it (payment reactivation, a reboot, an upgrade).

Related questions#

• "I paid my overdue invoice and the VPS is back, but my website is still down."
• "Why is my site offline after my VPS was unsuspended?"
• "MySQL/nginx didn't start after a reboot, why?"
• "How do I make services start on boot?"
• "My Docker containers are gone after a restart."
• "My app was running in screen and disappeared after a reboot."