# Allow for metric-export backoff when an inactive resource becomes active

> Why can a nonzero metric appear late in a diagnostic-settings destination after prolonged inactivity?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:29:54+00:00
- Modified: 2026-09-10T00:52:38+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Briefing
- DSE priority: Information
- Topics: IT
- Reading time: 2 minutes

## What you need to know

Why can a nonzero metric appear late in a diagnostic-settings destination after prolonged inactivity?

## Potentially affected

Inactive Azure resources exporting zero-valued platform metrics through diagnostic settings.

## DSE recommendation

Compare the export path's inactivity history with native metric observations before declaring a fresh collection failure.

## Article

## Source facts

Diagnostic-settings metric export progressively backs off for inactive resources exporting zero values. After one inactive hour the interval is fifteen minutes, and after seven days it can reach two hours. This can delay export of the next nonzero measurement. Once nonzero export resumes, the mechanism returns to its original three-minute latency. This behavior affects exported metrics, not metric-based alerts or autoscale. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings).

## Applicability

Use this timing explanation for the exported platform-metric path after a quiet period. Do not apply it to resource logs, or infer that an alert or scaling decision waits for the exported copy to arrive.

## DSE recommendation

Compare the export path’s inactivity history with native metric observations before declaring a fresh collection failure. Record when activity resumed, the first expected nonzero value and the destination being inspected. Avoid changing several collection settings simply to accelerate a diagnosis. Keep other evidence available for current service health while the exported measurement is pending.

## Verification

During an approved test, record the resource’s activity transition and compare native measurements with the later exported records. Check timestamps rather than assuming that arrival time is measurement time. Determine whether the delay is consistent with the documented backoff and whether subsequent nonzero exports return to the expected path. If evidence remains absent beyond the applicable behavior, continue routing investigation and retain the original observations instead of labeling every delay as normal.

## Official references

[Microsoft Learn: Diagnostic settings and inactive-resource metric export](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings). Source reviewed September 9, 2026.

## Primary reference

- Name: Diagnostic Settings in Azure Monitor - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Allow for metric-export backoff when an inactive resource becomes active,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/
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.