The Noisy Neighbor Metric
When you rent a "vCPU" from a cloud provider (like an AWS t3.micro), you are not getting a dedicated physical core. You are getting a time-slice of a physical core shared with other customers. The Hypervisor acts as the scheduler, deciding which VM runs on the physical CPU at any given moment.
Think of it like a shared taxi: you booked a ride, but the driver keeps stopping to pick up other passengers. You're in the car, but you're not moving. Steal Time is the metric that measures exactly this — the time your VM was ready to run but the hypervisor gave the CPU to someone else.
Steal Time (%st) is visible inside your VM via top and answers: "What percentage of time did my vCPU want to execute, but the Hypervisor said 'wait your turn'?"
| Steal Time | Interpretation |
|---|---|
| 0% | Your VM has the CPU whenever it needs it. |
| 0.1% – 1% | Normal background noise in shared cloud environments. |
| 1% – 5% | Mild contention. Monitor for trends. |
| 5% – 10% | Significant contention. Investigate the host. |
| >10% | Severe "Noisy Neighbor" effect. Action required. |
This is called the "Noisy Neighbor" problem — other VMs on the same physical host are consuming CPU, and your workload suffers even though your application is doing nothing wrong.
Key Point: Steal time is a hypervisor-level metric — it is not visible to the physical host's top command, only to the guest VM's. This asymmetry is important: a cloud provider's monitoring dashboard may show the physical host as healthy while your VM is experiencing 20% steal. Always instrument your VMs directly. Also note that burstable instance types (AWS T-series, GCP E2) have an additional layer: CPU credits. A T3 instance can burst above its baseline only while it has credits. Steal time and credit exhaustion are two distinct problems that can look identical from the application's perspective (sudden latency spikes) but require different fixes.
A common SRE interview scenario: "Your application latency doubled overnight. CPU is at 40%, memory is fine, no deploys happened. How do you diagnose it?" The steal time angle is a high-signal answer that demonstrates cloud infrastructure depth. Walk through: check %st in top, check cloud provider metrics for host-level CPU ready, check if it's a burstable instance that exhausted credits. Most candidates jump straight to application profiling — mentioning steal time first signals you understand the full stack.