What is Application Insights? A 2026 explainer

Application Insights has existed long enough to have three generations of SDK, two storage models and several names for the same tables, which is why “what is it” is a fair question even for people who already use it. This explainer describes it as it stands in October 2026.

What it is, in one paragraph

Application Insights is the application performance monitoring part of Azure Monitor. You create an Application Insights resource, copy its connection string into your app’s configuration, and add an instrumentation package. From then on every incoming request, outgoing call, exception and log line is recorded with timings and correlation IDs, so you can follow one user’s request through several services, see which dependency made it slow, and alert when the failure rate rises. It is a hosted service: there is nothing to run except the instrumentation in your own app.

The data model

Everything Application Insights stores is one of a small set of telemetry types. Each has a table, and each table has two names: the original Application Insights name, still used in the resource’s Logs blade, and the Log Analytics name used in the workspace.

Requests and dependencies are the spans of distributed tracing; logs live in traces “for legacy reasons”, as Microsoft’s data model page puts it. Availability results only exist if you set up availability tests, and custom events and metrics only if your code sends them.

The Azure Monitor vs Application Insights vs Log Analytics guide explains when to use which table name.

Where the data lives

Every Application Insights resource that still receives data is workspace-based: it stores telemetry in a Log Analytics workspace. If you don’t pick a workspace when you create the resource, Azure creates a managed one for it. The older “classic” resources, which kept data in their own store, are gone: ingestion into them stopped on June 15, 2025, after Microsoft’s automatic migration attempts from April 2025.

This matters for three practical reasons. Billing, retention and the daily cap are workspace settings. Queries written in the workspace use the App* table names. And several Application Insights resources can share one workspace, so the same query can cover them all.

How telemetry gets in

Classic SDK 2.x

The original Application Insights SDKs had their own API (TelemetryClient.TrackRequest, TrackEvent and friends), their own pipeline of telemetry initializers, processors and channels, and for ASP.NET an ApplicationInsights.config file. Microsoft’s status, quoted from the archived Classic API page: the .NET Classic API SDK 2.x “is deprecated and retires on 03/31/2027”, and the Node.js Classic API SDK 2.x “is retired”. A great deal of production code still runs on 2.x, which is why every guide on this site covers it.

Today

There are now four supported ways in, and the one to use depends on your stack:

• Microsoft OpenTelemetry Distro for new .NET, Node.js and Python apps: Microsoft.OpenTelemetry, @microsoft/opentelemetry (Node.js 22 or later) and microsoft-opentelemetry (Python 3.10 or later). One call registers the standard instrumentation and the Azure Monitor exporter.
• Azure Monitor OpenTelemetry Distro, the earlier family (Azure.Monitor.OpenTelemetry.AspNetCore, @azure/monitor-opentelemetry, azure-monitor-opentelemetry). Microsoft’s guidance for apps already on it is “no action needed”, and for Java it remains the current option, as an agent (Java 8+) or a native-image integration.
• Application Insights .NET SDK 3.x, an upgrade path for 2.x apps that keeps most of the TelemetryClient and TelemetryConfiguration API but runs on OpenTelemetry underneath. SDK vs the OpenTelemetry Distro compares the paths.
• Automatic instrumentation with no code change, on App Service (on by default for several stacks), Azure Functions and, in preview, AKS; see auto-instrumentation vs the SDK.

A minimal ASP.NET Core setup with the Microsoft OpenTelemetry Distro, reading APPLICATIONINSIGHTS_CONNECTION_STRING from the environment:

using Microsoft.OpenTelemetry;

var builder = WebApplication.CreateBuilder(args);

builder.UseMicrosoftOpenTelemetry(options =>
{
    options.Exporters = ExportTarget.AzureMonitor;
});

var app = builder.Build();
app.Run();

The same for an existing 2.x app upgraded to SDK 3.x, which needs no OpenTelemetry code of its own:

builder.Services.AddApplicationInsightsTelemetry();

Browser telemetry is the exception to the OpenTelemetry story: page views and browser timings come from the Application Insights JavaScript SDK, which isn’t OpenTelemetry-based. Native OTLP ingestion through an OpenTelemetry Collector also reached general availability in June 2026, which suits teams that already run a Collector.

For where the connection string goes in each package, see setting the connection string programmatically.

What you get in the portal

On top of the stored telemetry, the Application Insights resource adds the views most teams use daily: an application dashboard, Application Map (services and their dependencies, built from cloud role names), Live Metrics (a real-time stream that isn’t stored), Failures and Performance (drill-downs by operation, result code and dependency), transaction search, availability tests, and usage analytics for web apps (users, sessions, funnels, flows). Alerts, workbooks and Grafana dashboards come from Azure Monitor, and .NET apps can add Profiler and Snapshot Debugger.

Underneath every view is KQL over the same tables, so anything the portal shows you can query yourself. The KQL library starts with request latency percentiles by operation.

What it costs

You pay for data ingested into the workspace, per GB, with a monthly free allowance per billing account, and Application Insights tables keep 90 days at no extra charge. Live Metrics is free. Sampling is on by default in the .NET SDKs, the Microsoft OpenTelemetry Distro and the Java agent, which keeps volume predictable. The numbers and the levers are in Application Insights pricing and the sampling guide.

When not to use it

Application Insights is a good default for apps that run on Azure or whose team already lives in the Azure portal. Think twice when:

• Your organisation already standardised on another APM backend. OpenTelemetry lets you instrument once, so the exporter is the decision, not the code.
• You only need logs. If nobody will use traces, maps or request views, sending everything to a workspace table directly may be simpler.
• Log volume dwarfs everything else. High-volume debug logs cost the same per GB as requests. Fix the volume, or move AppTraces to the cheaper Basic plan and accept its query limits.

First-day checklist