A VPS gives you root. That is the selling point, and it is also the problem: every safety net shared hosting provided silently is now yours to build.
These are the failures we see most, roughly in the order they happen.
1. Sizing on RAM alone
RAM is the number on the pricing page, so it is the number people compare. Then the site is slow anyway, because the bottleneck was disk I/O. A database doing random reads against a throttled volume will crawl no matter how much memory is free.
Before buying, ask what the IOPS limit is and whether storage is NVMe, local SSD or network-attached. If the provider will not answer, that is an answer.
2. No swap, then a silent OOM kill
A VPS with no swap and a memory spike does not slow down — the kernel picks a process and kills it, usually the database, because it is the largest. The site starts erroring, someone restarts MySQL, it works again, and nobody learns why.
A modest swap file will not rescue a genuinely undersized server, but it converts a hard kill into degraded performance, which is something you can observe and act on. After any unexplained restart, check dmesg for an out-of-memory entry before blaming the application.
3. Backups on the same machine
A nightly dump to a local directory protects you from a bad deploy. It protects you from nothing else — disk failure, a compromised host, or an accidental recursive delete all take the backup with the server.
Backups belong on separate infrastructure. A provider snapshot is not a backup either: it lives on the same platform, usually in the same account, and disappears with it.
4. Never testing a restore
This is the one that actually hurts. Backups run for a year, everyone assumes they work, and the first restore attempt happens during an outage — when you discover the dump has excluded a database since a cron change in March, or the file has been zero bytes for months.
Restore to a scratch server once a quarter and write down how long it took. That number is your real recovery time, and it is always longer than anyone guessed.
5. Root SSH with a password
Port 22 is scanned continuously. Password authentication on root is an open invitation, and the auth log will show thousands of attempts within days of the server coming up.
Keys only, root login disabled, a non-root user with sudo, and fail2ban for the remainder. Fifteen minutes of work, once.
6. Databases listening on the public interface
MySQL and PostgreSQL will bind to all interfaces if configured to, and on a VPS there is no upstream firewall to save you. The database ends up reachable from the internet and gets found automatically — nobody has to be targeting you specifically.
Bind to localhost when the application is on the same box. When it is not, use a private network or a firewall rule allowing one address, not a range.
7. Logs filling the disk
Access logs, application logs, a debug flag someone left enabled. The disk hits 100%, the database can no longer write, and everything stops — with no obvious cause, because the application error says nothing about disk space.
Configure log rotation on day one and alert at 80% disk. The alert is the important half: rotation stops normal growth, but the alert is what tells you when something abnormal is producing it.
The pattern underneath
Six of these seven are not failures of the server. They are failures of noticing — nobody was watching memory, disk, or whether the backup produced a usable file. Basic monitoring, configured while things are calm, catches all of them before they become an outage.
If nobody on the team wants that job, managed hosting is the honest answer. Paying someone to watch a disk is cheaper than a day of downtime.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
