Most sub-$5 VPS offers pack too many customers onto the same hardware. You get a shell prompt and an IP address, but your CPU cycles vanish into steal time and your disk I/O crawls. I've seen support tickets where a site moved from shared hosting to a budget VPS and got worse performance because the hypervisor was hammered.
I tested six providers that advertise plans under five dollars a month. Not synthetic benchmarks—real workloads, sustained CPU tasks, network throughput under load, and actual support tickets. The goal was to separate the providers that maintain breathing room from the ones that cram instances until the host node chokes.
What causes bad performance on cheap VPS plans
Overselling is the root problem. A physical server might have 32 cores and 128 GB of RAM, but the host sells 80 VPS instances that collectively claim 160 cores and 320 GB. Most customers sit idle most of the time, so the math works—until it doesn't.
CPU steal time is the smoking gun. It measures how long your VPS was ready to run but the hypervisor gave your physical CPU cycles to someone else. Five percent steal is annoying. Twenty percent means your application is spending a fifth of its life waiting for CPU that you paid for.
Network congestion is harder to spot until you move real traffic. A provider might give you a gigabit port but share a single 10 Gb uplink among 40 VMs. During evening hours in the US or Europe, your throughput drops to double-digit megabits.
Disk I/O follows the same pattern. Cheap plans use spinning rust or older SATA SSDs with no I/O prioritization. One neighbor running a backup or a database migration pins the entire storage array.
The six providers I tested
I spun up the cheapest available plan from each provider in their US or EU regions, whichever had better advertised specs. Each instance ran for two weeks with a mix of idle time, sustained CPU load, disk write tests, and inbound/outbound network transfers.
Here's what I measured:
- CPU steal percentage under sustained single-threaded and multi-threaded load
- Network throughput during peak hours (18:00–22:00 local time)
- Disk write IOPS with
fiosequential and random patterns - Support response time for a non-urgent technical question submitted via ticket
I'm not naming the providers in ranked order because your workload matters. A plan that works for a personal blog might collapse under a busy API. But I will call out which ones showed consistent problems.
Provider A: CPU steal stayed under 3 percent
This one surprised me. Single-core plan, 1 GB RAM, NVMe storage. During two solid weeks, CPU steal never spiked above 3 percent even when I ran a CPU-bound compile job for six hours straight.
Network throughput averaged 180 Mbps down, 120 Mbps up during evening hours. Not blazing, but stable. Random write IOPS hovered around 8,000, which is respectable for a shared NVMe array.
Support answered my ticket in four hours. The tech knew what htop output meant and didn't ask me to reboot as a first step.
The catch: no DDoS protection beyond basic filtering, and the control panel is bare-bones. If you need one-click WordPress installers or automatic backups, look elsewhere. But if you can manage a server from SSH, this is solid.
Provider B: Network collapsed after 19:00 every night
Single-core, 2 GB RAM, SSD storage. CPU steal was acceptable at 5–8 percent under load. Disk I/O was middle of the pack.
But the network told a different story. From 07:00 to 18:00 UTC, I measured 400+ Mbps download. After 19:00, it fell to 30–50 Mbps and stayed there until midnight. Packet loss climbed to 2 percent during those windows.
I opened a ticket asking if there was a traffic shaping policy. Ten hours later, support replied that "network speeds may vary." That's not an answer.
If your traffic is international or off-peak, this might work. For a site with US evening visitors, you'll see complaints.
Provider C: CPU steal hit 40 percent during neighbor activity
This was the worst of the batch. Two-core plan, 2 GB RAM, SSD. For the first three days, steal time sat at 2–4 percent. Then another customer on the same node started something heavy—probably a backup or a render job—because steal jumped to 40 percent and my SSH sessions started lagging.
It lasted two hours, dropped back to normal, then spiked again the next evening. Over 14 days, I saw five separate incidents where steal exceeded 30 percent for more than an hour.
Disk writes were similarly unpredictable. Sequential writes would hit 200 MB/s one minute and 8 MB/s the next.
Support took 18 hours to reply and suggested I upgrade to a higher-tier plan. That's not a solution; that's upselling.
Provider D: Consistent mid-range performance
Single-core, 1 GB RAM, SSD. CPU steal averaged 6 percent, occasionally spiking to 12 percent for short bursts. Not perfect, but not disruptive.
Network was steady at 220 Mbps down, 180 Mbps up regardless of time of day. Disk IOPS stayed between 5,000 and 7,000 for random writes.
Support took nine hours to respond but gave a useful answer that included a specific sysctl tuning suggestion for the issue I reported.
This is the middle of the road. You won't get amazing performance, but you also won't spend your evenings troubleshooting mystery slowdowns.
Provider E: Good specs, terrible support
Two-core, 2 GB RAM, NVMe. On paper, the best deal in the group. CPU steal stayed under 4 percent even during sustained load. Network was fast—600 Mbps down during peak hours. Disk IOPS were excellent at 12,000+ random writes.
Then I had a kernel panic—not their fault, I was testing a custom kernel module. I opened a ticket asking if they had console access or a rescue mode.
Three days. No reply. I had to reinstall the OS from their panel and rebuild everything.
If you never need support and you know how to recover from your own mistakes, this is a strong choice. But the moment you hit a real problem, you're on your own.
Provider F: Aggressive resource limits
Single-core, 1.5 GB RAM, SSD. CPU steal was low at 3–5 percent, but the kernel was configured with strict CPU quotas. If you burst above a certain average over five minutes, your processes get throttled hard.
I ran a compile job and watched my CPU get pinned to 40 percent even though top showed no other load. After the throttle window reset, it jumped back to 100 percent.
Network and disk were fine. Support responded in six hours and explained the policy clearly: they limit burst CPU to prevent one customer from starving others. Fair enough, but it makes the VPS feel slower than the steal time suggests.
For bursty workloads—like a low-traffic WordPress site that occasionally rebuilds a cache—you'll notice the throttle. For steady background tasks, it's less of an issue.
What to look for when testing a new VPS
Don't trust the sales page. Spin up an instance and run your own checks.
Check CPU steal immediately
Install htop or use top and watch the st column. Run a CPU-bound task—compile something, run stress-ng, or encode a video. If steal climbs above 10 percent during sustained load, the host is oversold.
You can also check /proc/schedstat for more detail, but htop is faster.
Test network at different times
Use iperf3 against a public server in the same region or speedtest-cli if you prefer. Run it at 08:00, 14:00, and 20:00 local time for three days. If throughput drops by more than 30 percent during peak hours, expect problems when your traffic picks up.
Measure disk I/O with fio
Run a quick random write test:
fio --name=randwrite --ioengine=libaio --iodepth=16 --rw=randwrite \
--bs=4k --direct=1 --size=1G --numjobs=1 --runtime=60 --time_based
Look at the IOPS number in the output. For SSD-backed storage, anything below 3,000 IOPS is a red flag. For NVMe, expect 8,000 or higher.
Run it twice—once right after setup, and again a week later during evening hours. If the second run is half the speed of the first, the storage array is overloaded.
Open a support ticket before you need one
Ask a simple technical question—something like "What kernel version is running on this node?" or "Is IPv6 enabled by default?"
Time the response. If it takes more than 24 hours for a non-urgent question, assume you'll wait days during an actual outage.
When cheap VPS hosting makes sense
A sub-$5 VPS is not a production web server for a business site. But it works well for:
- Development and staging environments where occasional slowdowns don't matter
- Personal projects and learning where uptime is negotiable
- Lightweight services like a VPN endpoint, a monitoring agent, or a DNS resolver
- Backup destinations if you're pushing snapshots to remote storage
I've run small monitoring scripts and personal wikis on budget VPS plans for years without issues. The key is matching the workload to the resources and having a backup plan.
Alternatives if you need better performance
If you're hitting CPU steal or network limits on a cheap plan, jumping to a $10–15 VPS often doubles usable performance. Providers at that tier can't oversell as aggressively and still keep customers happy.
For bursty web traffic, consider a managed platform or a CDN in front of your VPS. Cloudflare's free tier or a cheap CDN plan can absorb traffic spikes while your backend hums along at low utilization.
If you need consistent CPU and disk, look for providers that advertise dedicated CPU cores. They cost more, but you're not fighting neighbors for cycles.
Start with a realistic workload test
The only way to know if a cheap VPS will work for you is to run your workload on it. Deploy a copy of your app, replay some production traffic, or run your CI pipeline. Watch CPU steal, measure network speed during peak hours, and open a support ticket.
If the numbers stay reasonable and support responds like they care, you've found a usable budget option. If steal spikes or your SSH session turns into molasses every evening, cancel and try the next one. At sub-$5 pricing, you can afford to test two or three before settling on one that works.