How to use CPU steal time to detect VPS / cloud overselling
Specs look fine but the app still stutters? Often the host is giving physical CPU to other tenants. Steal time is the clearest guest-visible signal of contention — and the best starting point for overselling detection.
What is CPU steal time?
Steal time (st in top, %steal in mpstat) is the share of time your vCPU was ready to run but the hypervisor scheduled someone else on the physical core.
It is not “high CPU usage.” It means “I wanted CPU and did not get it.” That distinction separates busy apps from host-level contention caused by overcommit or noisy neighbors.
What steal levels are normal?
Sensitivity varies by workload. Common peak-hour heuristics:
- Under ~2%: usually healthy
- ~2–5%: light contention; possible peak jank
- ~5–10%: moderate overselling risk; watch latency
- Sustained >~10%: severe contention — gather evidence, escalate, or migrate
Manual checks: three commands
During business peaks, sample for 1–5 minutes:
- top — watch st on the %Cpu line
- vmstat 1 — watch the st column
- mpstat 1 (sysstat) — watch %steal
Steal alone is not enough
Steal shows CPU contention, not the vendor’s exact overcommit ratio. Cross-check disk await/%util, sustained-benchmark cliffs, and peak vs off-peak windows.
If steal rises with p95 latency, treat it as an infrastructure problem — app micro-tuning will not fix missing CPU.
One-click evidence with CloudWorth
CloudWorth packages high-frequency steal sampling, disk-cache fraud checks, hardware-generation detection, and price collision into a zero-dependency probe — FinOps/support-ready output in about 10 seconds.
Start at getcloudworth.com, grab the probe command, and run it on the server you want to audit.