# Define request success before interpreting Application Insights outcomes

> When can an Application Insights request marked successful still represent an unsuccessful application outcome?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-162-define-request-success-before-interpreting-application-insights-outcomes/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:29:14+00:00
- Modified: 2026-09-10T00:55:35+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Explainer
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

When can an Application Insights request marked successful still represent an unsuccessful application outcome?

## Potentially affected

Application Insights request telemetry for web applications.

## DSE recommendation

Document application-specific request success semantics before relying on the default success classification.

## Article

## Source facts

Application Insights request telemetry describes execution initiated by an incoming application request. Its required Success field treats requests as successful unless explicitly marked false. For web applications, the documented default classifies response codes below 400, and also 401, as successful. Microsoft cautions that this classification can differ from application semantics. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/app/data-model-complete).

The source gives contrasting examples: a 404 can represent an expected empty result or a broken link; a redirect can fail a client that cannot follow it. A 206 response can indicate that only part of a submitted batch was processed successfully. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/app/data-model-complete).

## Applicability

Use this review for Application Insights request telemetry for web applications. Keep the transport response, the recorded success value and the application’s intended outcome as separate evidence fields. This brief does not redefine HTTP status codes.

## DSE recommendation

DSE recommends asking each application owner to describe success for its important request paths. Record expected empty results, authentication challenges, unsupported redirects and partial processing where applicable. Decide which cases require an explicit failure classification in instrumentation. Avoid applying one blanket status-code exception to unrelated operations merely to improve a dashboard percentage.

## Verification

Exercise approved examples of each documented outcome in a test environment. Compare the actual response, recorded Success value and business result. Have the owner explain any deliberate difference. Preserve representative telemetry and the classification decision so a later instrumentation change can be checked against the same cases.

## Official references

[Microsoft Learn: Application Insights telemetry data model](https://learn.microsoft.com/en-us/azure/azure-monitor/app/data-model-complete).

## Primary reference

- Name: Application Insights telemetry data model - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/app/data-model-complete
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Define request success before interpreting Application Insights outcomes,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-162-define-request-success-before-interpreting-application-insights-outcomes/
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.