# Azure VM High CPU, Upsize Recommendation > Flags Azure VMs above 80% average CPU or 90% memory used over 30 days and suggests the next larger size in the family. Source: https://zop.dev/integrations/azure/recommendations/azure-vm-high-cpu-upsize-recommendation --- ## Saturation has a cost too Rightsizing usually means shrinking, but a VM pinned near its limits is also mis-sized. Sustained high CPU queues work, stretches response times and leaves no room for a spike, and when available memory runs low the guest starts paging or killing processes. The bill does not show that cost; the users of the application do. ## Measuring a VM's load over a month ```bash az monitor metrics list \ --resource /subscriptions//resourceGroups//providers/Microsoft.Compute/virtualMachines/ \ --metric "Percentage CPU" "Available Memory Percentage" \ --aggregation Average --interval PT1H --offset 30d ``` `Available Memory Percentage` reports free memory, so memory in use is 100 minus that value. ## Either threshold is enough 1. The VM is running. 2. `Percentage CPU` averaged over the last 30 days is above 80%, **or** memory in use (100 minus the average `Available Memory Percentage`) is above 90%. 3. The VM has a positive monthly price, which is shown on the finding for context. The finding says which limit was crossed, CPU, memory or both, with the measured values. ## When there is no upsize advice If ZopNight has no `Percentage CPU` series for the VM, the rule does not run, even when memory data exists. A VM with no memory metric can still be flagged on CPU alone. Stopped or deallocated VMs are skipped. The rule looks at averages, so a VM that only spikes to 100% for a few minutes each hour will not be flagged; short bursts are better handled by autoscaling than by a bigger size. The opposite situation, a VM that is mostly idle, is covered by Idle Azure VM. ## No saving, by design The saving is $0 and the cost after the change is shown as unchanged. In practice the next size up costs more; the recommendation is about keeping the workload healthy, and the price difference is yours to weigh against the performance problem. ## Resizing to the next size up 1. Review CPU and memory in Azure Monitor and rule out a runaway process or a missing index as the real cause. 2. List the sizes the VM can move to: `az vm list-vm-resize-options --resource-group --name -o table`. 3. Resize: `az vm resize --resource-group --name --size `. 4. Confirm the application's response times and error rates improve. **Note** Microsoft's [resize guide](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/resize-vm) warns that resizing a running VM restarts it, and a deallocation may be needed when the new size is not available on the current hardware cluster.