What Is CPU Steal Time on a VPS

VPS CPU steal time is the percentage of time a virtual CPU could not run because the hypervisor was servicing another virtual processor. Linux records it as steal in /proc/stat; monitoring tools commonly show it as st or %steal. It measures scheduling delay, not CPU time used by a process inside your VPS, a security problem, or disk I/O wait.

How to read the metric#

A brief nonzero reading is not automatically a problem. There is no universal percentage at which steal time becomes dangerous. Sustained steal that occurs at the same time as slow requests, longer job runtimes, or increased application latency deserves investigation.

Collect repeated samples instead of relying on one snapshot:

vmstat -w 1 5
mpstat -P ALL 2 5
top

In vmstat, inspect the st column. In mpstat, inspect %steal for the overall and per-CPU readings. In top, check the CPU summary for st or %steal, where shown. The Linux kernel documents the underlying /proc/stat fields, and the Oracle Linux monitoring guide describes common resource-monitoring output.

Compare the samples with:

• Application latency, queue length, or job completion time
• CPU user and system time
• I/O wait
• Memory use and swap activity

Steal time and I/O wait describe different delays. Steal means the VPS was waiting to be scheduled on the host CPU; I/O wait means the workload was waiting on input or output. They can occur together, so a slow service should not be attributed to steal time without comparing the other measurements.

Why shared VPS plans can show steal time#

On a shared-CPU VPS, workloads from other virtual machines can delay access to the host's physical CPU. A persistent pattern may reflect shared CPU limits or contention, but it does not by itself prove that a provider is overselling its infrastructure.

If the pattern continues during a real slowdown, save timestamped command output and record the matching application symptoms. Ask the provider whether your plan has shared CPU limits and whether the host is experiencing contention. If the workload is CPU-intensive and the evidence persists, moving the workload or choosing dedicated CPU capacity, if available, can provide more predictable performance. A plan change is not necessary merely because a short sample contains a nonzero st value.