# My website didn't come back after a reboot or unsuspension Source: https://vpsdime.com/knowledgebase/troubleshooting/services-not-starting-after-reboot Last reviewed: 2026-07-02 Summary: The VPS is running and SSH works, but the website, app, or database is offline after a restart, typically right after paying an overdue invoice and being auto-reactivated. The cause is services that were started once by hand but never enabled to start on boot. How to diagnose in a minute, fix it with systemctl enable, handle Docker restart policies and screen/tmux apps, and verify with a test reboot. ## 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](https://vpsdime.com/knowledgebase/billing/billing-timeline), 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](https://vpsdime.com/knowledgebase/acceptable-use/bandwidth-overage), 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](https://vpsdime.com/knowledgebase/troubleshooting/502-503-errors), 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](https://vpsdime.com/knowledgebase/troubleshooting/disk-full), 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 ` (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](https://vpsdime.com/knowledgebase/support-coverage/software-and-server-management) 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](https://vpsdime.com/open-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."