# What is CPU steal time, and how do I check it on my VPS?

> CPU steal time on a VPS: what the st and %steal columns mean, 4 ways to check them, how to read the values. Dedicated vCPU VPS paid in crypto, no KYC.

- URL: https://cobaltfell.com/cpu-steal-time/
- Last updated: 2026-11-02
- Publisher: Cobaltfell (https://cobaltfell.com)

The one counter inside a VPS that shows when other tenants are taking your processor. What Linux means by it, four ways to read it, and what the numbers say about a shared or a dedicated vCPU.

**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).

*1. top: the st value in the %Cpu(s) line (press 1 for one line per vCPU, q to quit)*

```bash
top
```

*2. vmstat: one line per second for 60 seconds, steal in the st column of the cpu group*

```bash
vmstat 1 60
```

*3. mpstat: %steal for every vCPU, one report per second for 60 seconds*

```bash
mpstat -P ALL 1 60
```

*4. /proc/stat: steal as a share of CPU time over 10 seconds, with no extra package*

```bash
a=($(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.

*Patterns to look for while your own workload is running; on an idle VPS steal is not counted.*

| 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:

1. **Load it yourself.** Run your real job, or a CPU-bound test, and keep `mpstat -P ALL 1` open in a second terminal. Steal that tracks your load says the host has less free CPU than your plan suggests.
2. **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](https://cobaltfell.com/vps-benchmark/ "How do I benchmark a VPS with YABS or Geekbench 6?") gives the commands.
3. **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](https://cobaltfell.com/dedicated-vs-shared-vcpu/ "What is the difference between a shared vCPU and a dedicated vCPU on a VPS?") 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 `mpstat` makes 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](https://cobaltfell.com/dedicated-cpu-vps-price-index/ "What does a dedicated CPU VPS cost 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](https://cobaltfell.com/vps-for-postgresql/ "How much CPU and RAM PostgreSQL needs 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](https://cobaltfell.com/best-dedicated-cpu-vps/ "What is the best dedicated CPU VPS provider 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

1. [KVM-specific MSRs: MSR_KVM_STEAL_TIME](https://docs.kernel.org/virt/kvm/x86/msr.html) — The Linux Kernel documentation (checked 2026-11-02)
2. [proc_stat(5): kernel/system statistics](https://man7.org/linux/man-pages/man5/proc_stat.5.html) — man7.org (Linux man-pages 6.19) (checked 2026-11-02)
3. [top(1) manual page](https://man7.org/linux/man-pages/man1/top.1.html) — man7.org (procps-ng) (checked 2026-11-02)
4. [vmstat(8) manual page](https://man7.org/linux/man-pages/man8/vmstat.8.html) — man7.org (procps-ng) (checked 2026-11-02)
5. [mpstat(1) manual page](https://man7.org/linux/man-pages/man1/mpstat.1.html) — man7.org (sysstat) (checked 2026-11-02)
6. [systemd-detect-virt(1) manual page](https://man7.org/linux/man-pages/man1/systemd-detect-virt.1.html) — man7.org (systemd) (checked 2026-11-02)

---

Cobaltfell: Cobaltfell is a VPS provider with dedicated vCPU cores, paid in crypto with no ID upload and operated by DomaineGoat LLC, a Panama-registered company. Every vCPU is pinned to your server alone, on AMD EPYC 9004/9005 processors (Zen 4 / Zen 5) with NVMe storage, in Amsterdam (Netherlands), Zurich (Switzerland) and Bucharest (Romania). On the 12-month term, each plan is priced at least 25% under a named comparable dedicated-CPU plan, chosen among 6 no-KYC crypto VPS hosts and read on 2 November 2026.