CPU steal time is the percentage of time a virtual CPU was ready to run but the hypervisor did not schedule it on a physical core, because the core was busy serving other virtual machines or the hypervisor itself. Among server resources it is the metric that reveals contention invisible from inside the guest, and tools such as top, vmstat and mpstat report it as st or %steal.
Steal time exists only in virtualized environments: cloud instances, VPS plans and VMs on KVM, Xen or similar hypervisors. On bare-metal servers it is always zero. A persistently high value means a workload is receiving less CPU than its virtual core count suggests.
How steal time arises and is measured
A hypervisor multiplexes many virtual CPUs (vCPUs) onto fewer or equal physical cores and hyperthreads. When a vCPU has work but its physical core is occupied, the vCPU waits in the hypervisor run queue. The guest kernel cannot observe this directly, because from its point of view time simply passed.
To expose the gap, paravirtualized guests read a steal clock that the hypervisor maintains. On Linux under KVM this comes through a shared memory structure, and the kernel accounts it as a separate column in /proc/stat. Monitoring tools then express it as a share of elapsed time per CPU or across all CPUs.
The table below shows where steal time appears in common Linux tools and how each presents it.
| Tool | Field | Granularity |
|---|---|---|
| top | st in the CPU summary line | All CPUs or per CPU with key 1 |
| vmstat | st column | System-wide, per interval |
| mpstat | %steal column | Per CPU with -P ALL |
| sar -u | %steal column | Historical, per interval |
| /proc/stat | Eighth value on each cpu line | Raw counters in clock ticks |
Because the value is a share of wall-clock time, it combines with user, system, idle and I/O wait into a total of 100 percent. A server that shows 30 percent user, 10 percent system and 25 percent steal has effectively lost a quarter of its compute capacity to neighbors.
Interpreting steal time values
There is no universal threshold, but practitioners use rough bands that depend on how latency-sensitive the workload is. Short spikes are normal on shared hosts; what matters is a sustained level over minutes or hours.
| Sustained steal | Usual meaning | Typical response |
|---|---|---|
| Below 1 percent | Little or no contention | No action needed |
| 1 to 5 percent | Mild contention on a shared host | Watch trends, acceptable for most web loads |
| 5 to 10 percent | Noticeable slowdown under load | Investigate the host or instance type |
| Above 10 percent | Serious contention or throttling | Migrate, resize or change plan |
On burstable cloud instances, a sudden jump in steal often means the instance has used up its CPU credits and the provider is capping it to a baseline, for example 10 or 20 percent of a core. In that case the cause is a billing limit, not a noisy neighbor, and the fix is a different instance class rather than migration.
Steal time versus related CPU metrics
Steal time is easily confused with other signals that also make a server feel slow. The key difference is that steal is time the guest wanted but never received, whereas the others describe how the guest used or waited within the time it did receive.
| Metric | What it measures | Who causes it |
|---|---|---|
| CPU steal time | Runnable vCPU denied a physical core | Hypervisor and other guests |
| I/O wait | Idle CPU while I/O is outstanding | Storage or network latency |
| CPU throttling | Cgroup quota exhausted in a period | Container or cgroup limits |
| CPU utilization | Time spent running user and kernel code | The workload itself |
| Load average | Runnable and uninterruptible tasks | Demand on the guest scheduler |
Steal time is the most direct measurable symptom of a noisy neighbor, but not the only one: neighbors can also saturate shared caches, memory bandwidth or disks, which slows the guest without raising steal. A rising load average with flat utilization and high steal is the classic pattern of an overcommitted host.
Diagnosing and reducing steal time
The first step is to confirm a sustained pattern with historical data from sar or a monitoring agent, then correlate it with application latency. Steal that coincides with slow responses is worth acting on; steal during idle periods usually is not.
| Cause | Remedy | Trade-off |
|---|---|---|
| Overcommitted shared host | Stop and start to move hosts | Brief downtime, result not guaranteed |
| Exhausted burst credits | Fixed-performance instance type | Higher monthly cost |
| Budget VPS plan | Plan with dedicated vCPUs | Higher price per core |
| Strict latency needs | Dedicated host or bare metal | Highest cost, more management |
| Self-managed hypervisor | Lower the vCPU to core ratio | Fewer VMs per host |
Adding more vCPUs does not reliably help. On an overcommitted host, a VM with more vCPUs can wait even longer, because the hypervisor must find free cores for several of them. Right-sizing to fewer, better-provisioned cores is often more effective than scaling up.
Common mistakes when reading steal time
- Ignoring the st column because it is not part of the headline utilization figure, then blaming the application for slowness.
- Treating steal on a burstable instance as a provider fault when the credit balance explains it.
- Expecting steal on containers: a container sees the steal of its host VM, but cgroup throttling is reported elsewhere.
- Comparing values across hypervisors without care: some platforms do not expose a steal clock, so the metric reads zero even under contention.
- Averaging over a day and hiding short but severe peaks that hurt latency at busy hours.
For capacity planning, sustained steal means measured utilization understates real demand. Headroom calculations should be based on the throughput the service achieves, not on the guest believing that CPUs were idle.
Explained without jargon
A virtual server shares a physical machine with other customers. Each customer gets virtual processors, but the real processors are shared. CPU steal time shows how often your server had work to do but had to wait its turn.
Think of a shared kitchen with a few stoves. You are ready to cook, but someone else is using your stove. The minutes you spend waiting are steal time. A little waiting is normal. Long waits every day mean the kitchen is too crowded and it is time to move.
A typical use case
An online shop runs on a four-vCPU virtual server. Every evening between 19:00 and 22:00, page load times rise from about 300 milliseconds to over a second, yet the dashboard shows CPU utilization near 50 percent. The administrator runs mpstat -P ALL 5 during the slowdown and sees steal between 18 and 25 percent on every core.
Historical sar data shows that steal is close to zero in the morning and climbs only in the evening, which points to busy neighbors on the same host rather than to the shop itself. The team moves the server to a plan with dedicated vCPUs. Steal drops below 1 percent, evening response times return to normal, and the planned upgrade to eight vCPUs turns out to be unnecessary.