You bought a plan with two vCPU cores and a benchmark score you liked. A month later the site feels sluggish at random times of day, with no change in your traffic. Your provider insists nothing is wrong. They may be telling the truth: the problem is CPU steal, and on shared budget hosting it is often the single biggest gap between advertised performance and what you actually get.
CPU steal is not a bug and it is not usually a lie. It is a structural feature of how virtualisation on oversubscribed hardware works, and understanding it is the difference between diagnosing your slowdown correctly and paying for upgrades that do not help.
What CPU Steal Actually Is
On a physical server, the provider runs multiple virtual machines on shared physical cores. If every tenant were promised a full core and every tenant used it at once, the hardware could not cope. So providers overcommit — they sell more vCPU cores than physically exist, betting that tenants will not all peak simultaneously.
When your VM wants CPU time but the physical core is busy serving another tenant, your kernel waits. That waiting time is reported as “steal.” Your application sees a slow response; the monitoring inside your VM shows low CPU usage. From your side it looks like the server is idle yet slow. That contradiction is the signature of steal.
How to Measure It
You do not need a hosting panel to detect this. On Linux, run top or vmstat and look at the steal percentage — labelled st in top and the last column of vmstat. A sustained steal above roughly 5% is worth watching; above 10% during your peak hours, your “two cores” are not really yours.
- top — check the
stfigure in the CPU line. - vmstat 5 — watch the final column over a few minutes.
- htop — shows steal as a distinct bar, easiest for beginners.
Sample during your busiest window and during a quiet one. If steal spikes only at peak, you have a noisy-neighbour problem. If it is constant, the node is simply overcrowded all day.
Why Budget Plans Feel It Most
Cheap plans live on the most densely packed nodes. That is how the price stays low — the provider spreads the same hardware across more customers. Entry-level tiers are also the first to be throttled when a node is under pressure, because providers protect their premium customers first.
This does not make budget hosting a bad deal. It means you should size for the average with headroom for the peaks, and interpret “2 vCPU” as “up to 2 vCPU when available,” not a guarantee.
| Steal level | What it means | What to do |
|---|---|---|
| 0–5% | Normal shared tenancy | Nothing — you are being served fairly |
| 5–10% | Noticeable during peaks | Tune your app, re-measure, document it |
| 10–25% | Heavy oversubscription | Open a ticket; try a different node or provider |
| 25%+ | Node is effectively contended | Move. No amount of tuning fixes this |
What You Can Do About It
You cannot stop another tenant from being busy, but you can reduce your exposure:
- Ask for a different node. Support can often migrate you to less crowded hardware for free.
- Reduce your own CPU peaks. Caching, smaller image sizes and fewer concurrent workers lower your demand, so contention hurts less.
- Move noisy workloads off the box. Background jobs, backups and encoding can run overnight when steal is lowest.
- Check before you buy. Providers who publish honest fair-use policies tend to be less aggressive with oversubscription. Our budget VPS comparison notes which plans disclose their CPU allocation model.
Steal Is Not the Only Suspect
Before blaming the neighbour, rule out your own side. A slow disk, an unindexed database query, a runaway loop, or simply too little RAM causing swap thrashing will all look like a “slow server.” Check RAM and I/O as well as steal — if memory is exhausted and the machine is swapping, more CPU will not help.
Steal is the invisible tax on cheap hosting. Measure it, put a number on it, and decide with data whether to tune, migrate or upgrade. Almost nobody does this, which is exactly why it is worth doing.
Choosing Providers That Disclose Their Model
The best defence is buying from a host that is honest about how it allocates CPU. Look for a published fair-use or acceptable-use policy that states whether vCPU cores are shared or dedicated, and whether long-running CPU bursts are throttled. A provider that explains its model is far less likely to surprise you than one that only advertises a core count.
- Check whether the plan advertises “dedicated” or “shared” vCPU.
- Look for a written policy on sustained CPU usage and throttling.
- Read the reviews for complaints about slowdowns at peak times.
- Prefer providers that let you pick a node or migrate between them cheaply.
Benchmark the Node, Not Just the Plan
Run a short CPU benchmark at several times of day and compare the numbers. A consistent score suggests a well-managed node; scores that swing wildly point to heavy contention. Keep the results — they are the evidence you need if you ever ask support to move you, and they tell you whether the problem is the node or your own code.
When you are comparing options, favour plans that are transparent about CPU allocation. Our budget VPS comparison of providers flags the ones that publish clear resource policies, because on shared hardware the fine print matters more than the advertised core count.
