Quick answer
What is CPU steal time and how do I check it on my VPS?
CPU steal time is the share of time your vCPU was ready to run while the hypervisor ran another machine; at 10% steal, a busy job loses about a tenth of its time. On 2 November 2026, none of the 22 no-KYC crypto hosts promising dedicated CPU published a steal measurement, and neither had Cobaltfell. Linux shows steal as st in top and %steal in mpstat.
What exactly is steal time?
Steal time counts the moments when your virtual CPU wanted to work and the physical processor was busy with another guest. The Linux tools describe it in three slightly different ways:
top: "time stolen from this vm by the hypervisor".mpstat: the percentage of "involuntary wait" while the hypervisor "was servicing another virtual processor"./proc/stat: "the time spent in other operating systems when running in a virtualized environment", counted since Linux 2.6.11.
The kernel's KVM documentation adds the detail that makes the counter useful: steal is the time in which the vCPU did not run, and time during which the vCPU is idle is not reported as steal. An idle VPS cannot show steal, however crowded the host is. The number appears only when you ask for CPU and do not get it.
The figure comes from the hypervisor, which shares it with the guest kernel. A guest can only count what the hypervisor reports, which is one more reason to confirm a low value with a repeated benchmark.
How do I check steal time?
Four commands show it; run them while your real workload is running, not on an idle machine. top and vmstat come with the procps package on every common distribution. mpstat comes with sysstat (apt install sysstat on Debian and Ubuntu, dnf install sysstat on AlmaLinux and Rocky).
topvmstat 1 60mpstat -P ALL 1 60a=($(head -n1 /proc/stat)); sleep 10; b=($(head -n1 /proc/stat))
# fields 1-8: user nice system idle iowait irq softirq steal
all=0; for i in 1 2 3 4 5 6 7 8; do all=$((all + b[i] - a[i])); done
awk -v st=$((b[8] - a[8])) -v all=$all 'BEGIN { printf "steal: %.2f%%\n", 100 * st / all }'The first line of /proc/stat adds up all vCPU, in units of USER_HZ (a hundredth of a second on most systems). The script reads it twice, ten seconds apart, and divides the steal that accrued by all the time that passed. To confirm that you are on a virtual machine at all, systemd-detect-virt prints the hypervisor type, kvm on KVM.
How do I read the numbers?
No standard sets a "good" steal value, but the arithmetic is simple: a job that needs the CPU all the time gets at most 100% minus the steal. At 5% steal it gets about 95% of the time it asks for; at 25%, about three quarters. Read the pattern, not one sample.
| What you see | What it means | What to do |
|---|---|---|
| 0 on every vCPU while your job runs at full load | Nothing is taken from you, or the hypervisor reports no steal | Confirm with the same benchmark at two different hours |
| A few non-zero samples, then 0 again | Short contention on the host | Usually nothing; keep a log if your job is latency-sensitive |
| Steady steal under load, every second | Your vCPU queues behind other guests | Note the hours, measure for a day, send the log to the host |
Steal on one vCPU only in mpstat -P ALL | One of your threads lands on a busier part of the host | Mention the vCPU number in your ticket |
| Steal that rises at the same hours each day | Neighbours with a schedule: backups, batch jobs, peak traffic | Move heavy jobs to other hours, or move to dedicated vCPU |
| Any lasting steal on a plan sold as dedicated | The promise is not being met at that moment | Ask the host to explain or move the VPS |
Is my CPU shared with noisy neighbours?
If steal rises when you load the CPU and the rise follows the clock rather than your own work, other tenants are sharing your processor time. Three checks narrow it down:
- Load it yourself. Run your real job, or a CPU-bound test, and keep
mpstat -P ALL 1open in a second terminal. Steal that tracks your load says the host has less free CPU than your plan suggests. - Compare hours. Run the same benchmark in the morning and in the evening. On a dedicated vCPU, the two results should be close; how to benchmark a VPS with YABS or Geekbench 6 gives the commands.
- Read the plan. A plan sold with shared vCPU is allowed to show steal; that is what it costs less for. The page on the difference between a shared vCPU and a dedicated vCPU explains what each one buys.
A slow VPS with zero steal points elsewhere: disk waits (the wa column, time waiting for I/O), memory pressure or the application itself.
What causes steal time, and what fixes it?
Steal grows when the host has sold more busy vCPU than it has hardware threads to run them. When every guest asks for CPU at once, some have to wait, and the waiting is counted as steal in each of them.
What you can do, from least to most effort:
- Move the heavy work to hours when the host is quieter, if your workload allows it.
- Ask the host to move your VPS to a less loaded node; a log from
mpstatmakes the request concrete. - Change plan type. A dedicated vCPU removes other guests from your threads. Hosts that sell them, with the words each uses and the price per core, are listed in what a dedicated CPU VPS costs per core in November 2026.
According to Cobaltfell's survey of 2 November 2026, 22 of 51 VPS hosts that take crypto without an ID document promised a dedicated CPU in writing, and none of them showed a steal-time measurement on the pages we read.
Adding more shared vCPU rarely helps: more threads from the same crowded host wait in the same queue.
On a database, steal shows first in the slowest queries, as explained in how CPU steal affects PostgreSQL p99 latency on a VPS.
What steal should a Cobaltfell VPS show?
On a dedicated vCPU, steal time should sit at or near zero. We will publish the figure we measure on our own machines, with its date, and never an estimate. Each vCPU is held for one VPS: A vCPU is one hardware thread of the host processor. Yours are pinned one to one to your VPS and never lent to another customer, and the two threads of a physical core stay together, so every 2 vCPU make one whole core that no neighbour shares.
Our own YABS and Geekbench 6 results, together with the steal time we measure, will be published with their date once our first test machine is delivered. Until then we quote no performance figure of our own. Until that page carries a dated figure, run the commands above on your own VPS; if steal stays up while your job runs, the log is enough for a ticket. The best dedicated CPU VPS providers in 2026 are compared on the same written criteria, ours included. A person answers support emails within 12 hours, seven days a week, including help with SSH keys, reinstalls and firewall rules.
What other questions do people ask about CPU steal time?
Is steal time the same as iowait?
No. Steal (st) is time your vCPU wanted to run but the hypervisor ran another guest. Iowait (wa) is time the CPU sat idle waiting for disk or other I/O to finish. High iowait points to storage, high steal to CPU contention.
Why does top not show an st value?
The top manual notes that the st field may not be shown depending on the kernel version. On current distributions it appears in the %Cpu(s) line; on an old kernel or outside a virtual machine it may be missing or stay at zero.
Can a dedicated server show steal time?
A system running directly on the hardware, with no hypervisor under it, has nobody to steal from it, so the counter stays at zero. Steal only exists for a guest running under a hypervisor.
What steal value is too high?
No standard sets a limit. Use the arithmetic instead: at 10% steal a CPU-bound job gets about 90% of the time it needs. On a plan sold with dedicated vCPU, steal should stay at or near zero while you work.
Does steal time affect latency as well as throughput?
Yes. Each wait delays the request that was running on that vCPU, so steal shows up first in the slowest requests, the p99 of a database or an API, before it moves the average.
Sources (6)
- KVM-specific MSRs: MSR_KVM_STEAL_TIME — The Linux Kernel documentation (checked 2026-11-02)
- proc_stat(5): kernel/system statistics — man7.org (Linux man-pages 6.19) (checked 2026-11-02)
- top(1) manual page — man7.org (procps-ng) (checked 2026-11-02)
- vmstat(8) manual page — man7.org (procps-ng) (checked 2026-11-02)
- mpstat(1) manual page — man7.org (sysstat) (checked 2026-11-02)
- systemd-detect-virt(1) manual page — man7.org (systemd) (checked 2026-11-02)