CPU Steal Time Explained: Diagnose Noisy Neighbors on Vultr

This post contains affiliate links. If you purchase through our links, we may earn a commission at no extra cost to you.

Your app hasn’t changed. Your traffic hasn’t spiked. But your VPS feels sluggish anyway, and top looks almost normal — until you notice a small number in the corner you’ve probably never paid attention to. That number is CPU steal time, and it’s the closest thing Linux gives you to direct proof that another tenant on your host is eating into cycles you’re paying for. Here’s how to read it, when it actually matters, and what to do about it on Vultr specifically. We also ran these checks ourselves on four fresh Vultr instances on September 25, 2026 — the numbers, and why a clean reading isn’t a clean bill of health, are further down, along with a small analyzer you can paste your own vmstat output into.

What CPU Steal Time Actually Measures

CPU steal time — shown as %st in top, the st column in vmstat, and %steal in mpstat — is the percentage of time your virtual CPU wanted to run instructions but had to wait because the hypervisor gave the physical core to a different guest instead. It only exists in virtualized environments; on bare metal, there’s no hypervisor scheduling other tenants ahead of you, so the metric is meaningless there. Site24x7 puts it plainly: a reading like “20st” means 20% of total process time was spent waiting for a physical core to free up, with 100.0 as the theoretical ceiling.

Steal time is a different animal from %wa (I/O wait) or ordinary %sys/%usr load. Those measure your own workload’s behavior. Steal time isolates time lost specifically to the hypervisor scheduling someone else’s work ahead of yours — which is why it’s the most direct measurable signature of the “noisy neighbor” problem on shared infrastructure.

Opensource.com’s breakdown adds a wrinkle worth knowing: steal time isn’t caused only by an oversold host cramming too many CPU-hungry guests onto the same cores. It can also come from thread-pinning issues, where your vCPU and its emulator threads share a physical core with the hypervisor’s own I/O handling processes, or from background hypervisor-side work (monitoring, logging) competing for the same cores as your guest. And critically, standard monitoring stacks often don’t capture it by default — top or mpstat observation is frequently the only way you’ll ever see it.

How to Measure CPU Steal Time with vmstat, top, and mpstat

Three tools give you the reading, in increasing order of detail:

top — steal shows up in the %Cpu(s) summary line:

%Cpu(s): 2.1 us, 0.5 sy, 0.0 ni, 88.2 id, 0.0 wa, 0.0 hi, 0.0 si, 9.2 st

That 9.2 st at the end means 9.2% steal at that instant.

vmstat — run vmstat 1 for a one-second sampling interval. The rightmost column in the CPU section is labeled st, and watching it over a minute or two tells you whether steal is a blip or a pattern.

mpstat -P ALL 1 30 — the most useful of the three for diagnosis. The -P ALL flag breaks the reading down per core, sampled every second for 30 samples, with its own %steal column. That per-core view matters: it lets you tell whether steal is concentrated on one vCPU (possibly a pinning issue) or spread evenly across all of them (more consistent with host-wide contention).

CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle

GetPageSpeed’s diagnostic guide adds one more step worth running alongside these: iostat -x 1 10, to rule out storage-queue contention as a confounding factor. A high load average paired with low CPU usage often points to I/O wait, not CPU steal — the two get confused constantly, and conflating them sends you down the wrong fix.

our free VPS cost calculator can help if this diagnosis ends with “time to move plans” — more on that below.

When Steal Time Actually Means Trouble

A steal reading above zero isn’t automatically a problem — brief spikes happen on almost any shared host and aren’t worth chasing. What matters is whether it’s sustained. Two independent sources converge on the same rule of thumb: Scout Monitoring and GetPageSpeed both cite sustained CPU steal time above roughly 10% for about 20 minutes as the threshold where your VM is genuinely running slower than it should, and where it’s worth acting rather than just watching.

Below that, in short bursts, you’re probably seeing normal hypervisor scheduling noise. Above it, sustained, you have a real performance problem with a specific, fixable cause.

There’s also a useful diagnostic trick for telling “my workload just needs more CPU” apart from “the host is oversold”: compare steal time across multiple identical-spec instances. Scout Monitoring recommends this directly — if every instance of the same plan shows elevated steal, the workload itself is under-provisioned. If only one instance (or instances that happen to land on one particular physical host) shows it while otherwise-identical siblings don’t, that specific host is the problem, not your plan choice.

Why Shared VPS Plans Steal CPU From You in the First Place

A standard, non-dedicated VPS shares its underlying physical CPU cores — along with storage queues and network bandwidth — across every other tenant VM scheduled on the same host. The hypervisor time-slices those physical cores across all of them. When a neighboring tenant’s workload spikes, or the hypervisor’s own background processes need more cycles than usual, your vCPU can be forced to wait even though nothing about your own app changed. That’s the noisy-neighbor effect, and steal time is its direct fingerprint in your metrics.

This is the tradeoff baked into every shared-vCPU plan, on any provider: you’re paying less because you’re sharing physical hardware, and sharing means occasional contention is part of the deal, not a defect.

Vultr’s Plan Lineup: Shared vCPU vs Dedicated vCPU

Vultr’s compute lineup maps cleanly onto this shared-vs-dedicated split, which makes it a useful reference point if you’re trying to figure out which of their plans you’re actually running — or should be.

Regular Performance / Cloud Compute is the entry-level, cheapest tier. It runs on previous-generation Intel CPUs with standard (non-NVMe) SSD storage, and the vCPU is a shared time-slice of a physical core also used by other tenants — meaning performance can vary with what your neighbors are doing. WebHostingGeeks positions this tier for development and testing environments, low-traffic sites, and small databases: workloads that can shrug off occasional steal without anyone noticing.

High Frequency Compute is also shared-vCPU, but built on higher-clock-speed CPUs with local NVMe storage, aimed at workloads that need fast single-core throughput — small game servers, CMS sites. It starts at $6/month for 1 vCPU, 1 GB RAM, and 32 GB NVMe. It’s still a shared-tenancy product, not marketed as dedicated, so steal time is still possible on it in principle — but the faster hardware and NVMe I/O tend to reduce how much a given percentage of steal actually hurts in practice.

An independent third-party benchmark from Joshtronic (January 2025) ran sysbench tests head-to-head across Vultr’s Cloud Compute, High Frequency, and High Performance AMD tiers. High Frequency scored 1,339 CPU events/sec and 7,197 read-only MySQL transactions/sec, beating standard Cloud Compute’s 845 CPU events/sec and 4,045 MySQL tx/sec across nearly every metric — and in some tests, outperforming the pricier High Performance AMD tier too. The author called that result surprising given High Performance’s more premium positioning. Worth flagging: this is a snapshot from specific test hosts on a specific date, not a controlled steal-time measurement or a guarantee of current performance. Our own single 30-second sysbench run in Tokyo on September 25, 2026 (details in the test section below) put High Performance AMD well ahead instead — 4,303.83 events/sec vs 1,170.04 for High Frequency and 817.61 for Regular Performance — so treat both results as snapshots of particular hosts on particular days, not a fixed ranking.

Optimized Cloud Compute is Vultr’s dedicated-vCPU tier, and the distinction is explicit in Vultr’s own marketing: unlike typical Cloud Compute instances running on shared vCPUs, Optimized Cloud Compute runs on vCPUs dedicated to your workload — no other tenant can ever compete for those cores. It’s built on AMD EPYC CPUs with NVMe storage, aimed at workloads that need consistent performance: e-commerce platforms, game servers, larger databases. This is the tier to reach for once you’ve confirmed sustained steal on a shared plan and don’t want to deal with it again.

Bare Metal removes the hypervisor layer entirely — Vultr describes it as zero noisy neighbors and zero shared resources, with no metered CPU or IOPS limits. Pricing sits well above the Cloud Compute tiers, in the neighborhood of $120–185/month depending on plan and configuration. Because there’s no virtualization layer at all, CPU steal is structurally impossible on Bare Metal — the concept doesn’t apply.

New Vultr accounts get $300 in free credit, valid for 30 days — plenty of runway to spin up an Optimized Cloud Compute instance and compare its steal reading against whatever shared plan you’re currently on, side by side, before committing.

Pricing above reflects Vultr’s published plans as of late August 2026. VPS providers adjust tiers and pricing often enough that it’s worth a quick check on vultr.com before you buy — especially for Optimized Cloud Compute and Bare Metal, where exact entry pricing moves more than the well-publicized $6/month High Frequency starting point.

our full Cloud Compute vs High Frequency comparison

our Bare Metal vs Cloud Compute upgrade guide

What CPU Steal Looked Like on 4 Real Vultr Instances

Everything above leans on other people’s writeups, so we ran the check ourselves. On September 25, 2026 (around 08:37 UTC) we created four fresh Vultr instances, all 1 vCPU / 1 GB RAM on Ubuntu 24.04: three in Tokyo — one each on Regular Performance, High Frequency and High Performance AMD — plus a second Regular Performance box in Singapore. On each one we sampled steal at idle, then again while a single-threaded sysbench CPU test kept the vCPU fully busy. These are the exact commands:

vmstat 1 30                  # idle: 30 one-second samples
mpstat -P ALL 1 10           # idle: per-core %steal
sysbench cpu --threads=1 --time=30 run
(sysbench cpu --threads=1 --time=35 run >/dev/null &); sleep 2; vmstat 1 30   # steal under load

Here’s the Tokyo Regular Performance box — the cheapest plan in the test — while sysbench was running. The first row under the header is vmstat’s since-boot average (that’s why it shows 37 in us), and every live sample after it looks the same: us pinned at 100, st at 0.

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 2  0    268 102248  22852 650000    0    0  2117  2269  575    6 37  7 54  2  0  0
 1  0    268 102248  22852 650000    0    0     0     0 1008   49 100  0  0  0  0  0
 1  0    268 102248  22852 650000    0    0     0     0 1009   53 100  0  0  0  0  0
 1  0    268 102248  22852 650000    0    0     0     0 1013   57 100  0  0  0  0  0
 1  0    268 102248  22852 650000    0    0     0     0 1007   40 100  0  0  0  0  0
 1  0    268 102248  22860 649992    0    0     0    32 1015   58 100  0  0  0  0  0

That pattern held on all four instances. Every one of the 29 idle and 29 loaded samples on every box showed 0 in the st column, and mpstat averaged 0.00 %steal at idle on all four. One caveat on resolution: vmstat reports whole percentages, so a fraction of a percent of steal can still print as 0.

What this doesn’t show is that these plans are immune. Steal depends on what the other tenants on that physical host happen to be doing, and each of our samples covered 30 seconds on one host at one moment. Measured against the bar cited earlier — sustained steal above roughly 10% for about 20 minutes — we were nowhere near it, but a 30-second window can’t clear a host any more than one bad reading can convict it. That’s the whole reason the workflow below says to sample during the period when your app is actually slow and to compare against an identical instance: a clean reading on a fresh VM at 08:37 UTC says nothing about your VM at peak hour.

The sysbench column is a side note, but a telling one. With zero measured steal on both, the Singapore Regular box still scored 729.89 events/sec against its Tokyo twin’s 817.61, and the High Performance AMD instance did more than five times the Regular Performance figure. Whatever separated those numbers, it wasn’t steal — which is exactly why you check the st column before blaming the neighbors for a slow box.

Diagnosis Workflow: From Suspicion to Confirmed Noisy Neighbor

1. Measure first, don’t assume. Run mpstat -P ALL 1 30 or vmstat 1 across a window that includes the slow period. One elevated reading isn’t evidence — you’re looking for sustained steal, using the ~10%-for-20-minutes threshold above as your bar.
2. Rule out I/O wait. Cross-check with iostat -x 1 10 before concluding it’s steal and not storage contention — high load average with low CPU usage often means the disk queue, not the hypervisor scheduler, is your bottleneck.
3. Isolate cause from symptom. Compare steal across identical-spec instances. Uniform elevated steal means your workload has outgrown the plan. Isolated elevated steal on one instance means that specific host is oversubscribed.
4. If it’s confirmed and sustained on a shared plan: request a live migration to a different physical host first — GetPageSpeed cites a real case where a single provider-side migration immediately normalized load and responsiveness. If migration doesn’t fix it, escalate to the provider about potential overselling. For a durable fix rather than a repeat of this cycle, move to a dedicated-vCPU tier.
5. Reduce sensitivity to steal at the application level, independent of any infrastructure change: add a caching layer (Varnish, Redis) so fewer requests depend on raw CPU availability, decouple I/O from the request path, batch database writes, and use async workers so a short steal spike doesn’t translate directly into a user-facing delay.

It’s Not Just Vultr: Shared vCPU Is an Industry-Wide Pattern

This split isn’t unique to Vultr — it’s worth knowing if you’re weighing a provider switch as well as a plan upgrade.

DigitalOcean Basic Droplets share vCPUs with other Basic Droplets on the same hypervisor, the identical mechanism as Vultr’s Regular/Cloud Compute tier. DigitalOcean’s Premium and CPU-Optimized Droplet types are dedicated vCPU instead.

Hetzner runs the same split under different names: CX and CPX are shared-vCPU, while the CCX line offers dedicated AMD EPYC vCPUs explicitly positioned to eliminate noisy-neighbor variance — recommended for production databases, CI/CD pipelines, and anywhere consistency matters more than the lowest possible sticker price. A third-party comparison from Betterstack Community notes Hetzner’s dedicated CCX11 tier lands in a comparable price range to a standard shared DigitalOcean Basic Droplet, which means going dedicated isn’t necessarily the steep premium people assume.

our Vultr vs Hetzner comparison

our Vultr vs DigitalOcean comparison

If you’d rather not manage host selection and steal-time monitoring yourself at all, a managed platform like Cloudways sits on top of provider infrastructure (including Vultr’s own High Frequency tier) and handles server-level tuning for you — worth considering if your priority is shipping product, not babysitting mpstat output. It won’t eliminate the underlying shared-vCPU tradeoff on its cheaper tiers, but it takes the diagnosis-and-migration workflow above off your plate.

Who Should Upgrade to a Dedicated vCPU Plan (and Who Shouldn’t)

If you’ve confirmed sustained steal above the ~10%/20-minute threshold and your app is user-facing — an e-commerce checkout flow, an API with latency-sensitive clients, a database serving real traffic — the fix is straightforward: move to Optimized Cloud Compute or an equivalent dedicated tier. The cost difference over a Regular or High Frequency plan is real, but so is the cost of unpredictable latency on something people are paying you through.

If you’re running a dev/staging environment, a personal blog, a low-traffic side project, or anything where occasional slowdowns don’t cost you money or users, staying on a shared plan and just keeping an eye on vmstat periodically is the more rational call. Paying for dedicated cores you don’t need is its own kind of waste.

Measure Before You Upgrade

CPU steal time is one of the few metrics that tells you, unambiguously, when a shared host is the reason your app feels slow — but it only means something when you actually look at it. Run mpstat -P ALL 1 30 before you assume anything, rule out I/O wait as a confounder, and compare against identical instances before blaming your provider. Our own test is the reminder: four Vultr instances, two of them on the $5 Regular Performance tier, showed 0% steal in every sample on September 25, 2026 — a useful baseline, not a guarantee for the host your VM lands on.

If you confirm sustained steal on a Vultr Regular or High Frequency plan, the cleanest fix is Vultr moving to Optimized Cloud Compute — same provider, no migration hassle, and dedicated cores that make the problem structurally impossible going forward. If price is the deciding factor and you’re open to switching providers entirely, Hetzner’s CCX line is worth comparing directly against it. Either way: diagnose first, upgrade second. Guessing which plan to buy without ever running vmstat is how people end up paying for dedicated cores they didn’t need, or staying on shared ones they should have left months ago.

our full breakdown of Vultr’s pricing tiers