Where Budget VPS Plans Break First: IOPS, RAM, CPU Credits, Network

Budget VPS plans fail in a fixed order under sustained load: disk IOPS first, memory second, CPU credits third, network shaping fourth. That order is measurable. This page gives a four-part stress test you can run on any cheap plan in about 30 minutes, with the thresholds that separate "adequate" from "oversold".

Failure point	Trigger	Observable symptom	Typical tier affected	Pass threshold
Disk IOPS cap	Concurrent DB writes	High iowait, slow TTFB	$3–$10	>500 random 4K IOPS
Memory exhaustion	Traffic spike, cache growth	OOM killer, 502s	$3–$6	Swap I/O stays 0 under 80% load
CPU credit depletion	Sustained compute	Latency cliffs, throttling	Burstable plans	<20% throughput drop at 15 min
Network shaping	Bandwidth burst	Speed drop to 10 Mbps	Metered plans	>100 Mbps sustained for 3 min

Why the order of failure matters

Marketing specs describe peak capacity, not sustained behavior. On a $3–$8 plan the host is sharing storage, memory bandwidth and CPU scheduling with other tenants. Under sustained load the first constraint to bite is almost always the one the pricing page never mentions: IOPS. Once you know the order, you can design around the weakest link (small databases, aggressive caching at the edge, bursty workloads only) instead of discovering it in production.

Test 1: Disk IOPS with fio

Run a mixed random read/write workload that resembles a database, not a sequential file copy. Sequential tests flatter cheap storage; random 4K is what your app actually does.

• fio --name=randrw --ioengine=libaio --rw=randrw --bs=4k --size=512M --numjobs=4 --runtime=60 --time_based --group_reporting
• Watch the reported IOPS and, importantly, the 99th-percentile latency. Anything above 20 ms p99 on random 4K signals shared spinning or throttled storage.
• Re-run while a second process writes. This simulates the noisy-neighbor case that single-tenant tests miss.

Test 2: Memory pressure with a controlled allocator

Do not use a naive memory bomb that gets killed instantly. Allocate gradually and watch for the cliff where the kernel starts swapping:

• Use stress-ng --vm 1 --vm-bytes 80% --vm-hang 0 and monitor with vmstat 1.
• The moment si/so stay non-zero, you have found your real usable ceiling.
• Compare that ceiling to the advertised RAM. A 15–25% shortfall is normal overhead; anything beyond that is oversubscription you are paying for.

Test 3: CPU credit behavior

Burstable plans let you exceed baseline CPU for short periods. Sustained work drains the credit balance and your performance collapses to the floor. Measure it:

• Run sysbench cpu --threads=2 --time=0 run for 15 minutes.
• Record events/second every 60 seconds.
• If throughput drops more than 20% after the first 5–10 minutes, the plan is credit-limited and unsuitable for steady workloads like compilation or video encoding.
• Compare the floor rate to the baseline rate. A plan that falls to 25% of its starting throughput under sustained load is really a fraction of the vCPU you think you bought.

Test 4: Network shaping

Transfer a large file to a fast remote host and watch the rate over several minutes. Many budget providers allow a burst, then shape the connection. Sustained shaping at 10–50 Mbps is common; a plan advertised at "1 Gbps port" rarely sustains that for long. Use iperf3 against a public server and log the rate per second, not just the average.

Interpreting the results

1. If IOPS collapse under concurrent random I/O, keep databases small or move them off the box.
2. If the memory ceiling is far below advertised, treat the plan as one tier smaller than its label.
3. If CPU credits deplete, use the plan for bursty web traffic only.
4. If the network is shaped hard, add a CDN or cache aggressively at the edge.

The point is not to prove cheap plans are bad. Most are perfectly adequate for a personal site, a small API or a learning lab. The point is to know which constraint you will hit, so you can design around it instead of discovering it at 2 a.m. You can review value-focused plans with clearly stated resources on the budget VPS comparison page.

A repeatable checklist

• Run all four tests during the refund window, not after.
• Log the raw numbers next to price per usable GB and price per sustained IOPS.
• Re-test every six months. Oversubscription on a shared host changes as tenants come and go.
• Weight the weakest passing threshold, not the best one. A plan is only as good as its first bottleneck.

A plan that looks cheapest on the pricing page frequently stops being the cheapest once you divide price by delivered IOPS, usable RAM, and sustained network rate. That gap between advertised and delivered is exactly what a good value provider closes, and what you should measure before committing. For plans that publish renewal rates and resource limits openly, start from the main comparison table.