# Decide which caught exceptions deserve explicit Application Insights reporting

> Review handled failures that automatic instrumentation may not report.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-007-decide-which-caught-exceptions-deserve-explicit-application-insights-reporting/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:34:53+00:00
- Modified: 2026-09-17T16:35:03+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 1 minutes

## What you need to know

Review handled failures that automatic instrumentation may not report.

## Potentially affected

Use this review for a particular handled-error path in an instrumented application. Identify the language, instrumentation already installed, intended telemetry destination and the operational question that the exception should help answer. A handled exception alone does not establish a failed business transaction.

## DSE recommendation

DSE recommends choosing representative handled failures with the application owner before adding reporting.

## Article

## Source facts

Microsoft explains that some instrumentation libraries report exceptions automatically, while exceptions handled by application code ordinarily are not reported. The OpenTelemetry customization guide describes manual reporting for exceptions that should appear in failure investigations and end-to-end transaction views. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-add-modify).

## Applicability

Use this review for a particular handled-error path in an instrumented application. Identify the language, instrumentation already installed, intended telemetry destination and the operational question that the exception should help answer. A handled exception alone does not establish a failed business transaction.

## DSE recommendation

DSE recommends choosing representative handled failures with the application owner before adding reporting. Define which errors merit investigation, what context is safe to include and how repeated occurrences should be interpreted. Review the relevant language example in the current source and limit the first change to a controlled application build.

## Verification

Exercise the approved handled-error path and locate its exception record alongside the intended transaction. Also run a normal request and an automatically captured failure. Check that the added reporting supplies useful context without duplicating existing records or exposing request secrets. Preserve sanitized examples and the instrumentation configuration for later diagnosis.

## Official references

[Microsoft Learn: Add and Modify OpenTelemetry in Application Insights](https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-add-modify).

## Primary reference

- Name: Add and Modify OpenTelemetry in Application Insights - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-add-modify
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Decide which caught exceptions deserve explicit Application Insights reporting,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-007-decide-which-caught-exceptions-deserve-explicit-application-insights-reporting/
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.