# What is CPU steal time (%st)? Source: https://vpsdime.com/knowledgebase/technical-questions/cpu-steal Last reviewed: 2026-07-02 Summary: CPU steal time is the share of time a virtual CPU was ready to run but the hypervisor gave the physical core to someone else. Where the metric comes from, how to read it in top/vmstat/sar, what values mean, the first-order slowdown model, why it cannot be fixed from inside a guest, and how it differs from ordinary CPU saturation. ## Definition **Steal time** is the percentage of time a virtual CPU had work ready to run but could not run it, because the hypervisor had scheduled the underlying physical CPU to something else. It is time your virtual machine spent **involuntarily waiting for a physical core**: not idle (there was work to do), not blocked on disk or network (the task was runnable), simply not given hardware to run on during those moments. The metric exists only in virtualized environments. On physical hardware, a runnable task waits only for other tasks *on the same machine*; under virtualization, the machine itself can be made to wait, and steal time is how the guest kernel accounts for it. ## Where it comes from A hypervisor multiplexes **virtual CPUs onto physical cores** the same way an operating system multiplexes processes onto CPUs: vCPUs are, to the host, schedulable threads. When the sum of vCPUs across all guests exceeds the physical cores available, or simply when several guests demand CPU at the same instant, runnable vCPUs queue. The host informs each guest (through paravirtualized clock interfaces) how long its vCPUs sat in that queue, and the guest kernel reports it as steal. Two properties follow directly from this mechanism: - **Steal accumulates only under demand.** A vCPU that asks for nothing is never made to wait, so an idle guest shows near-zero steal regardless of how contended the host is. Steal is therefore meaningful only when measured **while your workload is actually running**. - **Steal is entirely a host-side phenomenon.** Nothing inside the guest, process priorities, `nice`, kernel or scheduler tuning, changes it, because the waiting happens below the guest's kernel. A guest can *measure* steal; it cannot *influence* it. A related, deliberate case: burstable or credit-based instance types (common at large clouds) enforce their CPU caps through the same mechanism, when the credit is spent, the hypervisor withholds cycles, and the guest sees it as steal. There, high steal is the product working as designed rather than contention. ## How to observe it The guest kernel exposes cumulative steal ticks as the eighth field of each CPU line in `/proc/stat`; the familiar tools present it as a percentage: - **top / htop**: the `st` value at the end of the CPU summary line (`%Cpu(s): ... 1.7 st`). - **vmstat 1**: the `st` column, sampled per second. - **sar -u** (sysstat): `%steal`, with history, which matters because steal is often periodic (a neighbor's nightly job) and a single glance misses the pattern. - **mpstat -P ALL** shows it per vCPU. Single samples mislead in both directions; judge steal by its **sustained value under your own load**, ideally from a time series covering at least a day. ## Interpreting the numbers - **0%**: your vCPUs get a physical core the moment they ask. The expected state on dedicated or lightly shared hosts. - **Transient low single digits**: ordinary scheduling coincidence, two guests occasionally wanting the same core at the same tick. Imperceptible for almost all workloads. - **Sustained 5 to 10%**: measurable. Throughput drops and, often more noticeable, **latency becomes jittery**, individual requests stall for scheduling gaps that the application cannot see or log, so response times develop an unexplained tail. - **Sustained above 10 to 20%**: severe contention. Everything stretches, and interactive workloads feel it constantly. A useful first-order model: sustained steal of *s* stretches CPU-bound wall-clock time by roughly a factor of **1/(1 − s)**, at 20% steal, a job that needs 60 CPU-seconds occupies about 75 seconds of real time. The model is approximate (it ignores burstiness and cache effects, which usually make the felt impact worse than the arithmetic), but it sets the scale: steal is not cosmetic once it is sustained. Steal also inflates the **load average**: tasks that are runnable-but-waiting count toward load, so a contended guest can show climbing load with modest `%us`, a signature worth recognizing. ## Distinguishing steal from your own saturation The CPU summary line separates the cases cleanly: - **High `us`/`sy`, near-zero `st`**: the machine is busy with *your* work. The remedy is inside the guest, profile, optimize, or add cores. - **Meaningful `st` while `us`+`sy` cannot reach the ceiling**: the machine is being made to wait. The remedy is structural, nothing inside the guest will change it. - **High `wa`** is a third, unrelated axis: waiting on I/O, not on CPU at all. ## What determines how much steal you see On any shared platform, steal is a function of decisions made on the host: the **overcommit ratio** (total vCPUs sold per physical core), the **demand patterns of co-tenants** (steal from neighbors is bursty and time-of-day shaped), and the **hypervisor's scheduling policy** (shares, weights, caps). At one extreme, hosts with pinned or reserved cores produce steal that is zero by construction; at the other, heavily oversold hosts produce chronic double-digit steal. Between providers and products, this ratio, not the advertised core count, is the variable that decides how much of a "4 vCPU" machine you actually get during busy hours. ## What a tenant can do 1. **Measure properly**: a `sar` or monitoring-agent time series of `%steal` under real load, over days, is objective evidence, and distinguishes chronic overcommit from a transient neighbor. 2. **Re-check your own side**: confirm the slowness correlates with `st` and not with `us`/`sy` (your code) or `wa` (your disk I/O). 3. **Structural remedies**: since steal cannot be tuned away from inside the guest, persistent high steal is resolved by moving the workload, to a host or product where CPU is dedicated or pinned, or by accepting the trade-off consciously where the workload tolerates it (batch jobs care little; latency-sensitive services care a lot). ## Still need help? You can [open a support ticket](https://vpsdime.com/open-ticket/). So we can help on the first reply, it's worth mentioning: - the VPS hostname or IP, - a `sar` or `vmstat` sample of %st under real load, with the timeframe it covers. ## Related questions - "What does st mean in top?" - "What is a normal CPU steal time value?" - "Why is my VPS slow with low CPU usage but high steal?" - "Can I reduce steal time from inside my server?" - "How does CPU overcommit cause steal time?" - "Why does my load average rise when steal time is high?"