# Distinguish autoscale metric failure from a rule that did not trigger

> Use the documented metric-failure and recovery events to classify missing decision data.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-140-distinguish-autoscale-metric-failure-from-a-rule-that-did-not-trigger/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:32:40+00:00
- Modified: 2026-09-17T16:42:36+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Use the documented metric-failure and recovery events to classify missing decision data.

## Potentially affected

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.

## Article

## 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](https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-diagnostics).

## 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](https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-diagnostics).

## Primary reference

- Name: Autoscale diagnostics - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-diagnostics
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Distinguish autoscale metric failure from a rule that did not trigger,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-140-distinguish-autoscale-metric-failure-from-a-rule-that-did-not-trigger/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.