# Read SDK retry counts as attempts, not an inventory of lost telemetry

> How should Application Insights SDK stats distinguish retries, drops and successful delivery?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-467-read-sdk-retry-counts-as-attempts-not-an-inventory-of-lost-telemetry/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:24:09+00:00
- Modified: 2026-09-10T02:08:04+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Explainer
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

How should Application Insights SDK stats distinguish retries, drops and successful delivery?

## Potentially affected

Application Insights applications using SDK or exporter versions supported by SDK stats.

## DSE recommendation

Correlate retry attempts with success and dropped-item series before declaring telemetry loss.

## Article

## Source facts

Application Insights SDK stats publishes per-process success, dropped-item and retry counters. Retry counts represent attempts and never decrease when those items later succeed; later delivery appears in the success series. The workbook calculates drop rate from dropped items divided by dropped plus successful items. An ingestion response of 206 can split one batch between accepted and rejected items, counted separately. Sampling, aggregation intervals and delayed buffering also prevent a simple equality with request-table row counts. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/app/sdk-stats).

## Applicability

Check the application’s SDK or exporter against the documented version prerequisites. Identify service instance, telemetry type, time grain and metric-name generation before combining counters. Microsoft documents different metric names for preview and generally available SDK stats; an upgrade review should account for mixed versions.

## DSE recommendation

Correlate retry attempts with success and dropped-item series before declaring telemetry loss. Keep retry volume distinct from a final delivery outcome in operational dashboards. When drops persist, inspect their codes and exporter logs rather than increasing retries indiscriminately. Separate application-level request success from exporter delivery success, and explain which one each chart describes. Use aligned observation intervals when comparing sources.

## Verification

Exercise a controlled delivery interruption in a test application and observe retries, later successes and any drops. Confirm that successful recovery does not require the historical retry counter to fall. For partial ingestion, examine item-level rejection evidence instead of treating the entire batch as accepted or lost. Retain the relevant dimensions and version so another reviewer can reproduce the interpretation without relying on the chart’s label alone.

## Official references

[Microsoft Learn: SDK stats in Azure Monitor Application Insights](https://learn.microsoft.com/en-us/azure/azure-monitor/app/sdk-stats). Source reviewed September 9, 2026.

## Primary reference

- Name: Software Development Kit (SDK) stats in Azure Monitor Application Insights - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/app/sdk-stats
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Read SDK retry counts as attempts, not an inventory of lost telemetry,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-467-read-sdk-retry-counts-as-attempts-not-an-inventory-of-lost-telemetry/
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.