# Scaling Target Too High
> Flags VM scale sets whose Percentage CPU scale-out threshold is above 90% and recommends lowering it to 70% for headroom.
Source: https://zop.dev/integrations/azure/recommendations/scaling-target-too-high
---
## Why a 95% scale-out threshold arrives too late
An autoscale rule compares a metric with a `threshold` over a `timeWindow` before it acts. In the
[autoscale settings schema](https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-understanding-settings),
Microsoft's own example scale-out rule fires when the scale set's average `Percentage CPU` is
greater than 85 over the past 10 minutes. That averaging exists to smooth out spikes, but it also
means the rule only reacts after a sustained period at the threshold.
Set the threshold at 95 and the instances have to sit near full CPU for the whole window before
autoscale even starts adding capacity. The new VMs then boot and warm up while the existing ones
queue requests, time out health probes or throttle. The fleet is not over-provisioned in this
state, it is under-protected: the setting saves little money and spends reliability.
## Reading the CPU threshold on a scale set's autoscale setting
Find the autoscale setting that targets the scale set, then print the threshold of every rule
that scales out on CPU:
```bash
az monitor autoscale list --resource-group my-rg \
--query "[].{name:name, target:targetResourceUri}" -o table
az monitor autoscale show --resource-group my-rg --name my-autoscale \
--query "profiles[].rules[?metricTrigger.metricName=='Percentage CPU' && scaleAction.direction=='Increase'].metricTrigger.threshold" \
-o tsv
```
A value above 90 is what this rule reports. `az monitor autoscale rule list --resource-group my-rg --autoscale-name my-autoscale`
shows the full rule, including its `timeWindow` and `timeAggregation`.
## The 90% line and what ZopNight reads
ZopNight takes the `Percentage CPU` scale-out threshold from the autoscale setting attached to
the scale set and raises a finding when all of these hold:
1. The scale set is provisioned successfully or running.
2. A numeric threshold was read from the autoscale setting.
3. That threshold is strictly greater than 90.
A threshold of exactly 90 passes. The finding reports the value it read and proposes 70 as the
new target.
## Scale sets this check leaves alone
When the autoscale setting cannot be read, or the threshold is missing or not a number, ZopNight
does not guess and does not raise a finding. A scale set with no autoscale setting at all is
reported by
VMSS Autoscale Setting Not Configured
instead. The opposite mistake, a threshold so low that the set scales out while mostly idle, is
Scaling Target Too Low, and rules that
can re-fire too quickly are covered by
Scaling Cooldown Too Short.
## A reliability finding with no dollar figure
This is a compliance check and carries no savings estimate. Lowering the threshold can add
instance hours, because the set scales out earlier. What you buy with them is time: capacity
arrives while the existing instances still have room to absorb load, rather than after users
have already felt the slowdown.
## Lowering the scale-out threshold to 70%
1. Open the scale set's autoscale setting (portal: the scale set, then **Scaling**), or export it
with `az monitor autoscale show`.
2. Change the CPU scale-out rule's threshold to 70, for example by recreating it with
`az monitor autoscale rule create --resource-group my-rg --autoscale-name my-autoscale --condition "Percentage CPU > 70 avg 5m" --scale out 1`
and deleting the old rule.
3. Keep a matching scale-in rule on the same metric with a clear gap below it. Microsoft's
[autoscale best practices](https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-best-practices)
warn that mixing metrics across scale-out and scale-in rules can cause flapping.
4. Watch scale events in the activity log for a few days and confirm the new instance count is
stable.