Two providers offer you the same thing: 4 vCPU, 8 GB of RAM, 80 GB of NVMe storage. One costs half as much as the other. On paper they are identical. Yet one of them will feel snappy at 3 p.m. on a busy Tuesday, and the other will stall while your database waits its turn. The difference has a name: overselling.
This isn’t fraud, exactly — it’s a business model. And once you understand how it works, you can spot it before you sign up, not three months later when your site is timing out.
What overselling actually means
Overselling, or oversubscription, is selling more of a resource than the physical machine actually has. A server with 256 GB of RAM might host plans that add up to 400 GB on paper. A 64-core box might sell 300 vCPU. The bet is statistical: most customers don’t use everything they bought at the same moment, so the provider packs more tenants onto each server and earns more per machine.
The bet usually pays off — for the provider. The cost lands on you, in milliseconds you can’t see on an invoice but can definitely feel.
It plays out differently for each resource:
- CPU. The most commonly oversold resource, because it’s the hardest for customers to measure. Many neighbours sharing the same physical cores means your processes wait in line for time on silicon you thought was yours.
- RAM. Sold through memory ballooning and swap. When the host runs short, your “guaranteed” memory gets quietly paged to disk, and everything that touched it slows to a crawl.
- Disk. Both capacity and IOPS get oversold. A noisy neighbour running a heavy import can saturate the shared storage and starve everyone else of throughput.
Contention ratios and CPU steal
The honest number nobody advertises is the contention ratio — how many customers share one physical resource. A 1:1 ratio on CPU means a dedicated core is yours alone. A 10:1 ratio means ten accounts can compete for the same core. Neither is wrong by definition; a 10:1 ratio is fine for a hobby blog and a disaster for a payment API. The problem is that providers rarely tell you the number, so you’re buying blind.
The clearest fingerprint of CPU oversubscription is steal time — the percentage of time your virtual CPU is ready to run but can’t, because the physical core is busy serving someone else. The Linux kernel exposes it directly, in the st column:
$ top %Cpu(s): 8.1 us, 2.3 sy, 0.0 ni, 71.2 id, 0.0 wa, 0.0 hi, 0.4 si, 18.0 st ^^^^ # 18.0 st = 18% of CPU time stolen by other tenants on the host
On a properly allocated machine that number sits at or near zero. Consistent double-digit steal time means you are paying for cores you don’t really get to use.
A spec sheet describes what you bought. Steal time describes what you actually received.
How to detect it before and after you buy
You don’t need special tools — just a few honest questions and a couple of commands.
Before you buy, ask the provider directly:
- Is the vCPU allocation dedicated or shared? What is the contention ratio?
- Is RAM guaranteed, or can it be ballooned/swapped under host pressure?
- Are disk IOPS guaranteed per plan, or shared across the node?
A provider that allocates honestly will answer plainly. Vague answers — “it depends on load,” “performance may vary” — are themselves an answer.
After you buy, measure:
- Watch
toporvmstat 1over a busy period and check thestcolumn for sustained steal time. - Run a quick disk benchmark at different times of day; if IOPS swing wildly, you’re sharing contended storage.
- Watch for symptoms: sluggishness that comes and goes on a daily rhythm, latency spikes unrelated to your own traffic, swap usage climbing while your app sits idle.
Note. A single steal-time spike during a backup window is normal. The red flag is *sustained* steal time under everyday load — that's the signature of a server packed past its limits.
Why Cybeward sells only what it has
We don’t oversell. Each plan maps to real, dedicated resources behind it: the vCPUs you buy are yours, the RAM is reserved rather than borrowed and paged, and storage runs on NVMe-backed Ceph with per-plan headroom instead of a shared pool that the loudest neighbour can drain.
That choice costs us margin. We fit fewer customers per server, which means we earn less per box than a provider running 2x oversubscription. We think it’s worth it, and not only on principle.
Honest allocation is boring in the best way: your benchmark on day one matches your benchmark on day ninety. No mysterious afternoon slowdowns, no "have you tried rebooting" tickets that lead nowhere.
Predictable performance is also cheaper for you. When capacity is real, you can size your server to your actual workload instead of over-buying to absorb someone else’s contention. You spend less time chasing phantom slowdowns and more time shipping.
And it’s better business for us, too. Oversold hosts generate angry tickets, refund requests, and churn — customers leave the moment they figure out why things feel slow. A server where every tenant gets what they paid for generates calm: people stay, because the thing simply works. Our 24/7 support is staffed by real people in Santiago, and we’d rather they spend their time helping you build than apologising for a neighbour’s import job.
The short version
Overselling is selling resources twice and hoping not everyone shows up at once. It’s invisible on the spec sheet and obvious under load. Ask about contention ratios, watch your steal time, and pick a provider whose numbers on day ninety match the ones they quoted you on day one.
That’s the whole promise behind selling only the resources we actually have.
