The accounting is what makes this reading actionable. Steal is the interval in which the guest had a runnable task, the vCPU asked for a physical core, and the hypervisor did not schedule it; Linux bills that time to steal instead of to your workload [14]. KVM exposes the counter for exactly that purpose, so a guest can observe time in which its vCPU was not executing [13]. What the counter does not carry is a cause. Host utilization, neighbour count, overcommit ratio, scheduler policy, vCPU pinning and host-side quotas are all invisible from inside the guest [15].
Add the columns up. User plus system plus softirq is 67.28% [19], and 67.28 plus 32.73 is 100.01, which is where the 0.00% idle comes from [21]. The write-up sets up the contrast itself: user and system near 100% with steal at zero and idle at zero is a sizing problem, and you either optimize the workload or buy more CPU [23]. This ledger is the other case. The same single vCPU with steal at zero would have executed about 1.49 times as much guest time [20]. The workload was asking for considerably more than that, with a runnable queue peaking at 11 [4] and load average between 3.5 and 4.0 on one vCPU [5].
It also was not a scheduler hiccup. The per-second samples stayed in a band from 30.69% to 35.35%, a spread of 4.66 points across the observation [17][18], and the equivalent stalled time works out to 19.64 seconds inside a 60-second window, accumulated in small pieces rather than one freeze [16]. Pressure Stall Information had "some" CPU pressure near 99 on the 10, 60 and 300 second averages [6], so the contention predates the measurement window. Available memory is a comforting metric that rules out exactly one thing [8].
Now the upgrade decision, which is where this matters. Buying a second vCPU buys a second claim on the same host. Whether that claim gets honoured depends on the host's spare capacity, and the guest cannot see it [15]. So the expected return on the upgrade is unknown before you pay, which is a bad property for the default remedy.
For the number to transfer to your machine, a fair amount would have to be true. It is one guest, one minute, under one production workload, with no synthetic load generator involved [12]. The author says plainly that this is not a review of the provider and not a claim about every VPS they run [10], and cancelled rather than resized [11]. And the awkward part for the framing in the dev.to headline, which contrasts AVA Hosting saying "no sharing" with Linux reporting 32.73% steal [9]: steal cannot distinguish a busy neighbour from a host-side cap applied to this one VM [15]. Both fit the data. A provider can be telling the truth about oversubscription and still hand a guest a third of its accounted time as steal, if the cap is per-VM.
In my own practice, sustained double-digit steal is a support ticket, not a code review, and I collect a week of samples before I file either. That threshold is mine, not something this minute of data establishes. What the data does establish is the order of operations: read the steal column before you read your own flame graph, because one of those two tells you whether the machine you are profiling exists.
