Enable Application Insights Live Metrics from code

Live Metrics is the fastest way to answer “is my deployment healthy right now”: requests, failures, dependency calls, CPU and memory, with about one second of delay. It’s also the quickest way to confirm a new instrumentation setup works, because ordinary telemetry can take a few minutes to appear in the portal.

What Live Metrics is, and isn’t

Two consequences follow. Live Metrics isn’t a substitute for alerts, because nothing is recorded when nobody is watching. And its traffic pattern is unusual: SDKs poll the Live Metrics endpoint once every five seconds to see whether anyone has the pane open, then switch to sending every second while someone does. Those calls aren’t tracked as dependencies, but network monitoring tools will see them.

What you can watch

Out of the box the pane shows request, dependency and exception rates (basic metrics), CPU and memory (performance metrics), and a live feed of sampled failed requests, failed dependency calls, exceptions, events and traces. Charts are aggregated twice, first on each server and then across servers, and you can switch either aggregation or pick a single server to see only its numbers.

Custom filters go further: a chart of only the requests to one URL that took longer than a second, or a feed of only one exception type. Support differs slightly by language:

Microsoft’s Live Metrics page also lists a minimum package version for each feature in Java, Node.js and Python; check it if you run an old release.

Custom filters are the reason to secure the control channel. Whatever you type into a filter (a customer ID, an email address) is sent back to every connected server. Without Entra authentication the portal makes you authorise connected servers in each session, warns you not to enter sensitive values, and Microsoft says unsecured channels are disabled automatically after six months.

Use it to verify a new setup

Live Metrics is the quickest test that instrumentation works end to end, because it skips ingestion and storage:

1. Deploy or start the app with the connection string set.
2. Open the Application Insights resource and select Live metrics under Investigate.
3. Send a few requests. Your server should appear within seconds, with request and dependency rates moving.
4. If the server appears but Logs stays empty after several minutes, the stream works and the problem is in the ordinary pipeline. If the server never appears, check the firewall and configuration rows in the troubleshooting table below.

Classic SDK 2.x

In the .NET SDK 2.x (deprecated, retiring March 31, 2027) Live Metrics comes from the QuickPulseTelemetryModule and a matching QuickPulseTelemetryProcessor, both in Microsoft.ApplicationInsights.PerfCounterCollector. With the standard setup it’s enabled by default for ASP.NET, ASP.NET Core, and console and worker apps.

Turn it off in ASP.NET Core

builder.Services.AddApplicationInsightsTelemetry(options =>
{
    options.EnableQuickPulseMetricStream = false; // default is true
});

Worker Service apps set the same option on AddApplicationInsightsTelemetryWorkerService.

Wire it by hand

Apps that build their own TelemetryConfiguration instead of using the ASP.NET Core or Worker Service integration have to add both pieces themselves: the processor into the chain, and the module initialised with the same configuration. This is Microsoft’s sample, minus its API key:

using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse;

var config = TelemetryConfiguration.CreateDefault();
config.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING");

QuickPulseTelemetryProcessor quickPulseProcessor = null;
config.DefaultTelemetrySink.TelemetryProcessorChainBuilder
    .Use(next =>
    {
        quickPulseProcessor = new QuickPulseTelemetryProcessor(next);
        return quickPulseProcessor;
    })
    .Build();

var quickPulseModule = new QuickPulseTelemetryModule();
quickPulseModule.Initialize(config);
quickPulseModule.RegisterTelemetryProcessor(quickPulseProcessor);

// Use the same configuration for every TelemetryClient, or its items won't reach Live Metrics.
var client = new TelemetryClient(config);

The rule that matters is in the last comment: Microsoft stresses that the live metrics module and any other collection modules must share one configuration. A second TelemetryConfiguration created elsewhere sends telemetry that Live Metrics never sees.

Microsoft’s sample still sets quickPulseModule.AuthenticationApiKey. Don’t copy that line: API keys used to stream Live Metrics were retired on September 30, 2025. To secure the channel, enable Microsoft Entra authentication; in 2.x that means a credential on the configuration, for example config.SetAzureTokenCredential(new DefaultAzureCredential()).

Classic ASP.NET apps configured through ApplicationInsights.config need both entries in the file, which Microsoft’s troubleshooting guide lists as the first fix for an empty pane:

<TelemetryModules>
  <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule, Microsoft.AI.PerfCounterCollector" />
</TelemetryModules>
<TelemetryProcessors>
  <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryProcessor, Microsoft.AI.PerfCounterCollector" />
</TelemetryProcessors>

The retired Node.js 2.x SDK needed an explicit setSendLiveMetrics(true) in its setup chain.

Today: SDK 3.x and the Microsoft OpenTelemetry Distro

SDK 3.x removed QuickPulseTelemetryModule and QuickPulseTelemetryProcessor from the public API; Live Metrics is managed internally and on by default. The switch depends on the package: EnableQuickPulseMetricStream on ApplicationInsightsServiceOptions or in appsettings.json for ASP.NET Core and Worker Service, <EnableQuickPulseMetricStream> in applicationinsights.config for classic ASP.NET, and EnableLiveMetrics on TelemetryConfiguration for the base package. A sample appsettings.json:

{
  "ApplicationInsights": {
    "EnableQuickPulseMetricStream": false
  }
}

The Microsoft OpenTelemetry Distro enables Live Metrics by default for ASP.NET Core, non-hosted .NET apps, Node.js and Python. Each has one switch:

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

In Node.js the option is azureMonitor.enableLiveMetrics; in Python, azure_monitor_enable_live_metrics=False. Microsoft’s configuration page carries its preview-terms notice on the Live Metrics sections for ASP.NET Core, Node.js and Python, even though the feature is on by default.

Authentication moves to the exporter’s credential: options.AzureMonitor.Credential in .NET, azureMonitorExporterOptions.credential in Node.js, azure_monitor_exporter_credential in Python.

Three limits are worth knowing before you go looking for a bug:

• ASP.NET on .NET Framework isn’t supported for Live Metrics with OpenTelemetry; use the Application Insights SDK there.
• Live Metrics requires the Azure Monitor sampler. Replacing the distro’s sampler with a generic OpenTelemetry one breaks it; see the sampling guide.
• Some paths have no Live Metrics at all: the standalone Azure.Monitor.OpenTelemetry.Exporter, Java GraalVM native apps, and Python apps instrumented automatically by App Service.

Troubleshooting an empty Live Metrics pane

If Live Metrics works but your ordinary telemetry doesn’t appear, the problem is elsewhere: the connection string, sampling or flushing. The telemetry channels guide covers the last of these.