Azure Monitor autoscale evaluates scale-in only when no scale-out rule triggers. Every scale-in rule must then trigger, and the engine chooses the result that removes the fewest instances. It also checks whether the proposed reduction would immediately trigger scale-out; this anti-flapping check can defer the reduction or reduce its size. Microsoft Learn.
\nCooldown is evaluated separately for each candidate rule, measured from the latest scale action. It is not one global waiting period copied from the rule that last acted. Microsoft Learn.
\nReview Azure Monitor autoscale profiles containing multiple metric-based scale-in rules. Establish the active profile first, but keep profile scheduling separate from this analysis of the rules inside it.
\nDSE recommends writing down each rule’s observed condition, proposed resulting capacity and cooldown eligibility for the same evaluation interval. Include any scale-out condition before attributing a missed reduction to the scale-in rule alone. Compare the most conservative permitted result with the operator’s expectation. Do not lower thresholds or delete a protective rule simply because one chart appeared to justify removing instances.
\nIn an approved test, exercise a case where only one reduction rule is satisfied, followed by a case where all are satisfied. Compare the resulting capacity with each rule’s proposal and check whether a reversal would follow. Preserve the rule configuration, recent scale-action time and observed outcome so the decision can be reconstructed without relying on a single metric screenshot.
\n