A cloud VM that suddenly feels sluggish, with no matching spike in your own application's CPU or memory graphs, is one of the more confusing problems in cloud operations. The process list looks normal, the load average looks normal, and yet requests take longer to complete. The cause is often something the operating system reports honestly, but that most monitoring dashboards do not surface by default: CPU steal time, burst credit exhaustion, or storage IOPS throttling.
This is a practical diagnostic path for that situation, in the order that finds the cause fastest.
Step 1: check CPU steal time first
On a physical dedicated server, top and vmstat report user time, system time and idle time, and that is the whole picture. On a cloud VM, there is a fourth category: steal time, labeled %st in top and st in vmstat.
vmstat 1 5Steal time represents CPU cycles your virtual machine was ready to use but the hypervisor gave to another tenant on the same physical host instead. A healthy cloud VM under normal load shows steal time close to zero. Steal time consistently above 5 to 10 percent during a period when your application feels slow is a strong signal that the underlying physical host is oversubscribed, sometimes called a noisy neighbor problem.
Steal time is not something you can fix from inside your own VM. The two realistic responses are moving to a larger instance size, which is often backed by less oversubscribed hardware, or moving to a dedicated instance type or a physical dedicated server if the workload is consistently CPU sensitive.
Step 2: check whether you are on a burstable instance type
Instance families like AWS T-series, Azure B-series and similar burstable types do not give you full, continuous access to their listed vCPU performance. They accumulate CPU credits during idle periods and spend those credits during busy periods. Once the credit balance reaches zero, CPU performance is throttled down to a baseline level that can be a fraction of the advertised speed.
On AWS, check the CPUCreditBalance and CPUSurplusCreditBalance metrics in CloudWatch. A balance trending toward zero right before the slowdown started is the signature of this problem. Azure and Google Cloud expose equivalent burst-credit metrics under their own monitoring dashboards.
If your workload runs sustained load rather than occasional spikes, a burstable instance type is the wrong choice regardless of how it performs when idle. Moving to a standard, non-burstable instance family removes this ceiling entirely.
Step 3: check storage IOPS and burst balance
Cloud block storage volumes, such as AWS gp3 or Azure Standard SSD, provide a baseline IOPS level and allow short bursts above that baseline using an accumulated credit balance, similar in concept to burstable CPU credits. A volume that has been under sustained write load, such as a database doing frequent commits or a log-heavy application, can exhaust its burst balance and drop to baseline performance, which is often a small fraction of the burst rate.
iostat -x 1 5Look at the %util column and the await column. A %util value near 100 percent combined with rising await times, while your application's actual data volume has not changed, points to storage throttling rather than an application problem. Confirm against the provider's own volume-level IOPS and throughput metrics, since iostat shows what the guest OS sees, not the underlying physical contention.
The fix is usually provisioning a higher baseline IOPS tier, moving to a storage type with no burst ceiling, or moving hot data such as database files to local NVMe instance storage where the instance type supports it.
Step 4: rule out network-level throttling
Smaller cloud instance types often cap network throughput below what the network interface itself is theoretically capable of, and some providers apply the same kind of credit-based bursting to network bandwidth that they apply to CPU and storage.
iftopor, for a quick synthetic check:
iperf3 -c <a host you control>If throughput plateaus well below the documented limit for the instance size and stays flat under repeated tests, the instance's network allocation, not your application, is the ceiling.
Step 5: separate this from an application-level problem
Before concluding the cause is infrastructure-level, confirm the slowdown is not coming from the application itself. Check slow query logs on the database, check for a recent deployment, and check whether request volume has actually increased. Steal time, credit exhaustion and IOPS throttling are common causes of a slow cloud VM, but they are not the only causes, and treating every slowdown as an infrastructure problem can hide a real application regression.
A reasonable order of elimination is: application logs and recent deployments first, then vmstat for steal time, then the provider's burst-credit metrics for CPU and storage, then network throughput. This order finds the most common causes fastest without requiring provider support access.
What to do once you have a cause
Steal time from a noisy physical host is resolved by moving instance size or type, not by tuning your own application. Burst credit exhaustion on CPU or storage is resolved by moving to a non-burstable tier sized for sustained load rather than occasional peaks. Network throttling is resolved by moving to a larger instance type with a higher documented network allocation.
In all three cases, the underlying lesson is the same: cloud performance is not a fixed number on a specification sheet, it is a range that depends on instance type, storage tier and what else is happening on the shared hardware underneath you. Sizing a cloud server for sustained production load means sizing for the guaranteed baseline, not the best-case burst figure.
iServerSupport provides cloud server management for AWS, Azure and Google Cloud instances, including this kind of performance diagnosis, monitoring for steal time and credit exhaustion before they become an incident, and right-sizing instances so a workload is not quietly running on a burstable tier it has outgrown.
Get an experienced server engineer involved
We diagnose and manage infrastructure you already own or rent, with practical help matched to the issue in this guide.
