# Do not equate Log Analytics export failures with a count of lost records

> How should a continuous-export operator interpret retries, duplicate delivery and destination failures?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-315-do-not-equate-log-analytics-export-failures-with-a-count-of-lost-records/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:26:41+00:00
- Modified: 2026-09-10T01:40:02+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

How should a continuous-export operator interpret retries, duplicate delivery and destination failures?

## Potentially affected

Continuous Log Analytics data exports to Azure Storage or Event Hubs.

## DSE recommendation

Investigate destination failures using retry context and record-level reconciliation instead of treating a failure counter as lost-event evidence.

## Article

## Source facts

Log Analytics export rules continuously send new records from selected tables to Storage or Event Hubs. When a destination lacks capacity or availability, export retries continue for up to twelve hours and can produce duplicate records. Data is discarded if the destination remains unavailable after that retry period. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-data-export).

Export Failures counts unsuccessful requests, including throttling and access failures. Microsoft explicitly says this counter does not establish missing data because failed attempts are retried. Records Exported counts records in successful operations. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-data-export).

## Applicability

Apply this review to continuous Log Analytics data exports to Azure Storage or Event Hubs. These rules export arrivals from configuration time, not historical records already in the workspace. Keep historical export work separate from recovery of a current delivery problem. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-data-export).

## DSE recommendation

DSE recommends giving destination availability an operational owner and responding before the retry window is exhausted. Track the failed-request interval, throttling or access cause, and recovery time. Define how the receiving system identifies repeated records. Do not report an exact loss count from the failure metric alone or assume successful-request totals prove unique delivery.

## Verification

Compare representative source records with received records across an approved test interval. Include delayed and repeated arrivals in the reconciliation. Preserve the destination metrics, timestamps and unresolved record differences. Close the issue only after distinguishing retry attempts, confirmed duplicates and records whose delivery remains unverified.

## Official references

[Microsoft Learn: Log Analytics data export rules](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-data-export).

## Primary reference

- Name: Log Analytics Data Export Rules in Azure Monitor - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-data-export
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not equate Log Analytics export failures with a count of lost records,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-315-do-not-equate-log-analytics-export-failures-with-a-count-of-lost-records/
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.