Steal is not a load metric. It is the fraction of time a vCPU was ready to run and the hypervisor did not schedule it [4]. That distinction is why TLS breaks first. The server side of a handshake is a burst of asymmetric crypto, which is CPU work, and CPU work only completes when your vCPU gets a slot. On this box the handshake alone reached roughly nine seconds against 127.0.0.1, with the client and the server inside the same VM [11][13]. With production traffic gone, the same local request still ranged from 61 ms to 3.355 seconds [12], a spread of about 55x [5].
The capacity arithmetic is worth writing down. In the first sample, user plus system came to 5.49% of measured CPU time [1]. Spread across the two vCPUs the plan provides [1], that is roughly 0.11 vCPU doing anything useful [2]. Once the box was quiet, user plus system was 2.54%, about 0.05 vCPU [3], and steal moved 1.59 points in the wrong direction [4]. vmstat samples in that window ran 91% to 98% steal, with as many as 15 runnable processes waiting [10].
The comparison the writeup draws is the useful template. A genuinely CPU-bound guest should read about user 80, system 10, steal 0, idle 10 [5]. This one read user 4, system 1, steal 93, idle 1 [6], and individual samples stayed in a band from 89.85% to 96.48% [7], so it was not one unlucky moment. What shows up in the socket table follows from an accept loop that rarely runs: around 450 established connections with 122 orphaned and 110 in FIN-WAIT-1, an HTTPS listen queue near 40 [14], and nginx 504s logged from 128.657 to 142.857 seconds [15]. Raising worker counts here gives the scheduler more things not to schedule.
For the reading to transfer to your machine, two conditions have to hold. The steal has to persist across repeated samples rather than appear in one. Your own user and system time has to be low enough that the run queue cannot plausibly be yours. Even then, guest metrics have a ceiling, and the author states it himself: they cannot prove intent, and they cannot show that cores assigned to him were handed to another customer, only that runnable work went unscheduled [17]. He also says the post is not a negative review of REGXA and that he is not advising anyone for or against the provider [18]. That is the honest framing, and it is also the limit of what a tenant can establish from inside the guest. The actionable part survives anyway: when the steal column holds the time, the levers you own are a different host node or a different provider, not your config.
