Distinguish autoscale metric failure from a rule that did not trigger

Source facts

Microsoft logs MetricFailure when autoscale cannot determine the metric used by a scaling rule, and MetricRecovery when that metric becomes available again. Its failure-event example describes scaling out to the default capacity when that capacity exceeds the current count. These events describe a missing or restored input, rather than a normal below-threshold observation. Microsoft Learn.

Applicability

Use this review when an autoscale investigation includes unavailable metric data. Identify the autoscale setting, target resource, relevant metric and active profile. Keep missing input separate from a valid measurement that simply does not satisfy a rule, and inspect actual capacity rather than assuming a fallback occurred.

DSE recommendation

DSE recommends building an incident timeline from the failure and recovery events before adjusting thresholds. Compare the active default capacity with the observed count and ask the monitoring owner to investigate the missing input. Preserve the existing rule configuration while determining whether the problem belongs to metric availability or the scaling decision.

Verification

Inspect the event names, times and resource identifiers alongside metric availability and instance-count history. Record whether recovery was observed and whether a capacity change actually completed. Confirm representative measurements continue after recovery. Leave unexplained gaps visible in the incident record instead of treating a later successful query as proof that the earlier scaling input was available.

Official references

Microsoft Learn: Autoscale diagnostics.