Application Insights errors and missing telemetry — Entra ingestion errors, where telemetry is lost, sampling, daily cap and limits
Why telemetry doesn't reach Application Insights and how to find the step that loses it — the ingestion endpoint's 400 Authentication not supported, 401 and 403 for Entra-only resources, network, DNS, TLS and private link causes, sampling that drops traces by design, the daily cap, throttling and size limits, duplicate distros, and the Node.js exporter's known gaps.
markdownreferencev1CA4F-D7PBstage: operatetrust: officialservice: monitorinterface: anyApplication Insights no datamissing telemetryHTTP/1.1 400 Authentication not supportedv2/track v2.1/trackHTTP/1.1 401 Authorization requiredHTTP/1.1 403 Unauthorized Application InsightsMonitoring Metrics Publisher missingingestion endpoint DNSAzure Monitor Private Link DNS overwriteTLS 1.2 ingestiondaily cap Application Insights 100 GBthrottling 32000 events per secondtelemetry item 64 KB64000 items per batchproperty value 8192 characterssampling missing transactionstracesPerSecond 5two OpenTelemetry distrosduplicate telemetryoperation name missing dependency Node.js exporterAPPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVELclassic Application Insights no longer ingests
Application Insights errors and missing telemetry
Telemetry can be lost at five places: the SDK or agent doesn't send it; the network blocks the ingestion endpoint; ingestion rejects or throttles it; the pipeline delays or drops it (service health); or the portal fails to query it. Microsoft's support article includes PowerShell and curl scripts that post a sample record straight to the ingestion endpoint: if that succeeds from the app's host, the problem is the SDK configuration; if it fails, it's the network.
Ingestion responses (any language)
| Response | Cause → fix |
|---|---|
HTTP/1.1 400 Authentication not supported | The resource is Entra-only (DisableLocalAuth) but the SDK sends unauthenticated telemetry to v2/track. Configure a credential so it uses v2.1/track |
HTTP/1.1 401 Authorization required | The SDK is set up for Entra but can't get a token: look for Azure Identity errors in the SDK logs (wrong client ID, no identity on the host) |
HTTP/1.1 403 Unauthorized | The token's identity lacks Monitoring Metrics Publisher on the Application Insights resource |
| Throttled | Above 32,000 events per second (measured over a minute) |
| Item dropped or truncated | Item over 64 KB; more than 64,000 items per batch; property values over 8,192 characters; names over 150; messages over 32,768 |
Causes that send nothing at all
| Cause | Check → fix |
|---|---|
| DNS doesn't resolve the ingestion endpoint from the connection string, or resolves it wrongly | nslookup the IngestionEndpoint host from the app |
| Firewall or proxy blocks outbound HTTPS to it | Test with the support article's curl script |
| Client still offers TLS 1.0/1.1 | Ingestion requires TLS 1.2 |
| Several Azure Monitor Private Link scopes touching the same network overwrite each other's DNS records | The hub's reading: keep one AMPLS per shared DNS (Microsoft's private link design guidance covers this) |
| The distro starts after the libraries it should instrument | Load it first (--import, or the first require) |
| A classic Application Insights resource | It no longer ingests: convert to workspace-based |
| Instrumentation-key-only configuration | Use the full connection string (regional endpoints) |
Telemetry that's there but incomplete
- Sampling by design: the Microsoft OpenTelemetry Distro keeps 5 traces per second by default; Failures and Performance views look incomplete for busy apps. Raise the rate or use
samplingRatio. - Daily cap: Application Insights defaults to 100 GB per day; at the cap, collection stops until the workspace's reset hour (
reference/monitor/log-analytics-workspaces.md). Some data beyond the cap still arrives. - Duplicates: two distros or an SDK plus codeless monitoring in the same app send everything twice: keep one.
- Node.js exporter known issues: dependency telemetry lacks the operation name; request and dependency telemetry lack the device model; database dependency names omit the server, so same-named tables on different servers aggregate together.
Turning on the exporter's logs
APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL=VERBOSE, APPLICATIONINSIGHTS_LOG_DESTINATION=file and APPLICATIONINSIGHTS_LOGDIR=<folder>, or in code diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.ALL) from @opentelemetry/api.