What Is CPU Steal Time?

What Is CPU Steal Time?

CPU steal time means your virtual machine wanted to use the CPU but had to wait because the physical CPU was being used elsewhere. It is the amount of time a virtual CPU is ready to run work but cannot because the hypervisor is using the underlying physical CPU for another virtual machine or workload.

From inside the VM, the application is ready to execute, but the CPU time it expects is temporarily unavailable. Linux records this waiting period as steal time, commonly shown as %steal, %st, or st.

CPU steal is mainly relevant to virtualized environments. It can appear on cloud instances, virtual machines, and Kubernetes nodes running on VMs, particularly when physical CPU resources are shared between multiple tenants or workloads.

CPU Steal Time at a Glance

How Does CPU Steal Time Work?

A physical server may host several virtual machines. Each VM sees one or more virtual CPUs, or vCPUs, but those vCPUs ultimately depend on physical CPU cores controlled by the hypervisor.

Suppose your VM has work ready to execute. If the physical CPU is available, the hypervisor schedules your vCPU and the work runs normally. If another VM is using that CPU, your vCPU may have to wait even though your operating system has runnable work.

That waiting period becomes CPU steal time.

A simplified view looks like this:

Application needs CPU → VM schedules work → Hypervisor cannot provide physical CPU → VM waits → CPU time is recorded as steal

Linux defines steal time as the time spent by a virtual machine on other operating systems while running in a virtualized environment. Red Hat describes it similarly as CPU time requested by a guest VM but not provided because the host allocated the resource elsewhere.

What Causes CPU Steal Time?

The most common cause of CPU steal is contention for physical CPU resources. Multiple virtual machines may share the same host, and when several of them demand CPU at the same time, the hypervisor decides how the available physical CPU is divided.

CPU steal can also appear when the VM is subject to CPU quotas or other host-level resource limits. From inside the guest, these situations may look similar because the application has runnable work but cannot receive all the CPU time it wants.

Shared CPU environments are particularly relevant. DigitalOcean, for example, explains that shared CPU Droplets can experience steal while waiting for CPU resources controlled by the hypervisor, whereas dedicated CPU products provide dedicated access to their vCPU resources.

The exact behavior depends on the cloud provider, virtualization platform, instance type, and host configuration. Steal time should therefore be interpreted together with knowledge of where the VM is running.

What Does High CPU Steal Time Mean?

High CPU steal time usually means your VM is not receiving all the CPU time it could use. The guest operating system may have runnable processes, but the hypervisor is preventing them from running immediately because the physical CPU is busy elsewhere.

This can lead to slower application execution even when the processes inside the VM do not appear to consume unusually high CPU. Red Hat notes that large amounts of steal time indicate CPU contention and can reduce guest performance.

For example, an API normally responds in 200 milliseconds but suddenly begins taking 600 milliseconds. Application traffic has not changed, and memory and disk I/O look normal. If steal time increased significantly during the same period, part of that latency may come from the VM simply waiting to receive CPU time.

How Does CPU Steal Affect Application Performance?

CPU steal reduces the effective CPU capacity available to the virtual machine. If a VM reports 10% steal during a measurement interval, roughly one-tenth of the CPU time represented by that interval was unavailable to the guest because the hypervisor was servicing something else.

The impact depends heavily on the workload. A lightly used background service may tolerate occasional steal without noticeable effects, while a latency-sensitive API, database, build system, or real-time workload may experience slower responses much sooner.

High steal can contribute to increased response times, slower request processing, growing queues, lower throughput, or longer batch jobs. The effect becomes more visible when the application already needs most of the CPU capacity available to it.

Is CPU Steal the Same as CPU Usage?

No. CPU usage measures how much CPU time the guest operating system is spending on application or kernel work. CPU steal measures CPU time the guest wanted but did not receive from the hypervisor.

This distinction matters during troubleshooting. Increasing application CPU usage usually means processes inside your VM are doing more work, while increasing steal suggests the bottleneck may exist outside the VM.

Datadog exposes stolen CPU separately from user, system, idle, and I/O wait CPU metrics for this reason. Its system.cpu.stolen metric represents the percentage of time a virtual CPU waits while the hypervisor services another virtual CPU.

CPU Steal Time vs. I/O Wait

CPU steal and I/O wait can both make applications appear slow, but they describe different problems.

CPU steal means the VM wanted CPU time, but the hypervisor did not provide it. I/O wait represents time associated with tasks waiting for I/O operations, such as disk activity, to complete.

If steal is high, investigate virtualization and CPU capacity. If I/O wait is high, disk or storage performance may deserve more attention.

Looking at both metrics together helps avoid chasing the wrong bottleneck.

How Do You Check CPU Steal Time on Linux?

Linux exposes CPU steal information through several common system tools. You normally do not need special debugging software to perform an initial check.

Check CPU Steal With top

Run:

top

Look at the CPU summary near the top of the screen. The st value represents steal time.

For example:

%Cpu(s): 35.0 us, 5.0 sy, 55.0 id, 0.0 wa, 0.0 hi, 0.0 si, 5.0 st

In this example, steal time is 5%.

Check CPU Steal With vmstat

Run:

vmstat 1

The st column shows the percentage of CPU time stolen from the VM. The Linux vmstat documentation defines st as time stolen from a virtual machine.

Watching several samples is more useful than relying on one reading because short spikes may disappear quickly.

Check CPU Steal With mpstat

You can also use:

mpstat -P ALL 1

The %steal column shows steal time across the CPUs. mpstat is useful when you want to examine individual virtual CPUs rather than only the overall system average.

Microsoft's Linux performance documentation, for example, shows %steal as one of the CPU measurements returned by mpstat.

Check /proc/stat

Linux also exposes the underlying counters through:

cat /proc/stat

The CPU lines contain several values, including user, system, idle, I/O wait, interrupt, and steal time. The Linux kernel documentation defines the eighth CPU field as stolen time in virtualized environments.

For ongoing production monitoring, it is usually easier to collect this information automatically rather than manually checking /proc/stat.

What Is a Good CPU Steal Time?

There is no universal percentage that defines acceptable CPU steal for every environment.

Ideally, steal should remain very low or close to zero. A small temporary increase may have little impact, while sustained steal becomes more important when it coincides with higher application latency, lower throughput, rising load, or growing request queues.

A latency-sensitive production service may react badly to a level of steal that would be harmless for a background worker. The better approach is therefore to establish the normal baseline for each workload and alert when steal increases significantly above that baseline or begins affecting application performance.

Avoid interpreting CPU steal alone. Look at it together with CPU utilization, load, traffic, application latency, throughput, errors, and infrastructure changes.

CPU Steal Time in Cloud Environments

CPU steal is closely associated with cloud computing because many cloud VMs run on shared physical infrastructure. The cloud provider's hypervisor decides how physical CPU resources are allocated between virtual machines.

This does not mean every cloud VM will report meaningful steal. The behavior depends on the provider and instance architecture. For example, Microsoft states that %steal is not applicable to Azure because its VM platform does not use CPU overprovisioning in this way.

On platforms with shared CPU products, contention can be more relevant. DigitalOcean explicitly documents CPU steal for shared CPU Droplets, while its dedicated CPU products provide dedicated access to the assigned vCPU resources.

AWS CloudWatch Agent also exposes cpu_time_steal for Linux systems, defining it as time spent in other operating systems in a virtualized environment.

Because cloud architectures differ, always interpret steal time according to the instance type and provider rather than assuming the same behavior everywhere.

CPU Steal Time in Kubernetes

Kubernetes itself does not create CPU steal, but Kubernetes worker nodes are often virtual machines. If the underlying VM experiences CPU contention at the hypervisor level, every pod running on that node can be affected.

This can make troubleshooting confusing. Several pods may become slower at the same time even though none of them has reached its Kubernetes CPU limit and the node's normal CPU metrics do not immediately explain the degradation.

Checking host-level steal time can reveal that the problem exists below Kubernetes. If high steal aligns with increased pod latency or slower workloads on one node, the underlying VM or physical host may deserve investigation.

CPU steal should therefore be monitored at the node level, then correlated with Kubernetes workloads, application latency, pod CPU usage, and node load.

How Do You Monitor CPU Steal Time?

CPU steal is most useful when viewed over time rather than as a one-time reading. Continuous monitoring helps identify whether a spike was brief or whether the VM repeatedly loses CPU during busy periods.

A useful dashboard can combine steal time with CPU user time, system time, idle time, load average, application latency, request throughput, and errors. If steal increases while application latency rises and idle CPU falls, CPU contention becomes a much stronger investigative lead.

You should also compare affected hosts. If one VM shows unusually high steal while identical instances handling the same workload remain healthy, the difference may point toward the underlying host or resource allocation rather than the application itself.

How Do You Reduce CPU Steal Time?

Because CPU steal happens outside the guest operating system, optimizing application code inside the VM may not solve it. The response depends on why the hypervisor is withholding CPU.

Moving the workload to a different host or VM can help if the issue is host-level contention. In environments you control, reducing the number of competing VMs, increasing CPU allocation or priority, or changing resource quotas can also reduce contention. Red Hat recommends increasing guest CPU priority or quota, or running fewer guests on the host when steal is high.

In cloud environments, another option may be moving from shared CPU infrastructure to an instance type with more predictable or dedicated compute capacity. Scaling out can also reduce the CPU demand placed on each individual VM.

Before making changes, confirm that CPU steal actually correlates with the application problem. Moving to a larger instance will not fix slow storage, database contention, network latency, or inefficient application code.

How to Troubleshoot High CPU Steal Time

Start by confirming that steal is sustained rather than a brief spike. Compare it with application latency, request throughput, load average, CPU idle time, and the time the problem started.

Next, compare similar virtual machines. If only one instance experiences high steal while others serving the same workload remain healthy, the physical host or VM placement may be involved.

Also check whether the application itself has recently changed. A traffic increase or new CPU-heavy workload can increase demand and expose contention that was previously harmless.

If the evidence consistently points toward hypervisor-level CPU availability, consider moving or resizing the VM, reducing contention, changing instance class, or involving the cloud or virtualization provider.

The Bottom Line

CPU steal time measures CPU capacity that a virtual machine wanted but could not use because the hypervisor allocated the physical processor elsewhere. Linux exposes this information through /proc/stat and tools such as top, vmstat, and mpstat.

High steal time can reduce the effective CPU available to applications and contribute to higher latency, lower throughput, and slower processing. It is particularly relevant for virtual machines running on shared compute infrastructure.

CPU steal should not be investigated in isolation. Monitor it alongside application latency, CPU utilization, idle time, load, traffic, errors, and other infrastructure signals to determine whether virtualization-level contention is actually affecting users.