{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/", "slug": "dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active", "url": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/" }, "title": "Allow for metric-export backoff when an inactive resource becomes active", "summary": "Why can a nonzero metric appear late in a diagnostic-settings destination after prolonged inactivity?", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "managed-it", "label": "Managed IT operations", "alt": "A controlled technology lifecycle progressing from assessment to approved production.", "card_url": "https://update.dsesecurity.com/assets/editorial/managed-it-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/managed-it-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:29:54+00:00", "modified_at": "2026-09-10T00:52:38+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 243, "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.", "primary_source": { "name": "Diagnostic Settings in Azure Monitor - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts

\n

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.

\n

Applicability

\n

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.

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official references

\n

Microsoft Learn: Diagnostic settings and inactive-resource metric export. Source reviewed September 9, 2026.

", "content_text": "Source facts\nDiagnostic-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.\nApplicability\nUse 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.\nDSE recommendation\nCompare 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.\nVerification\nDuring 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.\nOfficial references\nMicrosoft Learn: Diagnostic settings and inactive-resource metric export. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nDiagnostic-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).\n\n## Applicability\n\nUse 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.\n\n## DSE recommendation\n\nCompare 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.\n\n## Verification\n\nDuring 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.\n\n## Official references\n\n[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." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/", "url": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Allow for metric-export backoff when an inactive resource becomes active", "item": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/", "url": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/", "headline": "Allow for metric-export backoff when an inactive resource becomes active", "description": "Why can a nonzero metric appear late in a diagnostic-settings destination after prolonged inactivity?", "abstract": "Why can a nonzero metric appear late in a diagnostic-settings destination after prolonged inactivity?", "articleBody": "Source facts\nDiagnostic-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.\nApplicability\nUse 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.\nDSE recommendation\nCompare 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.\nVerification\nDuring 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.\nOfficial references\nMicrosoft Learn: Diagnostic settings and inactive-resource metric export. Source reviewed September 9, 2026.", "datePublished": "2026-09-10T00:29:54+00:00", "dateModified": "2026-09-10T00:52:38+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-122-allow-for-metric-export-backoff-when-an-inactive-resource-becomes-active/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Allow for metric-export backoff when an inactive resource becomes active" }, "articleSection": [ "IT" ], "keywords": [ "IT", "Briefing", "Information priority" ], "genre": "Briefing", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 243, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Diagnostic Settings in Azure Monitor - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings" } } ] } }