Application Insights pricing: what you pay for, and how to cut the bill

Prices on this page are retail USD list prices for East US, read from the Azure Retail Prices API on October 21, 2026. Your region, currency and any agreement discount change the numbers, not the shape of the bill.

What you actually pay for

Classic resources stopped ingesting on June 15, 2025, so every Application Insights resource that still receives data stores it in a Log Analytics workspace, and the workspace does the billing. That has two consequences. The Application Insights resource has no separate line for its data, and every pricing option of Log Analytics applies to it, commitment tiers included.

GB here means 10^9 bytes of billed size. Microsoft measures a record’s billed size from a string representation of its columns, which on average comes out about 25 percent smaller than the incoming JSON, and standard columns such as _ResourceId and _BilledSize aren’t counted.

What drives the volume

Each telemetry item is a row, and some types are far more numerous than others. In a typical web app, in roughly the order they surprise people:

• Dependencies. Every outgoing HTTP, SQL and Azure SDK call is a row. A request that makes 20 database calls writes 21 rows before it logs anything.
• Traces. Logging at Information level through ILogger or another logger turns every log line into a row in traces (AppTraces).
• Exceptions. A handled exception thrown in a loop can outweigh all your requests, because exception rows carry stack traces.
• Requests and page views. One row per request or page view, plus browser timings if the JavaScript SDK is on the page.
• Metrics and performance counters. Small per row and pre-aggregated, but sent continuously by every instance.

Find your biggest table before changing anything. In the workspace:

union withsource = TableName App*
| where TimeGenerated > ago(7d)
| where _IsBillable == true
| summarize BilledGB = round(sum(_BilledSize) / 1e9, 2) by TableName
| order by BilledGB desc

Microsoft’s troubleshooting guide then breaks the top table down by operation_Name, cloud_RoleInstance, dependency type and target, and trace message, which usually points at one noisy call or log statement.

Classic SDK 2.x

Apps on the classic .NET SDK 2.x (deprecated, retiring March 31, 2027) already sample: adaptive sampling targets five items per second per server host in ASP.NET and ASP.NET Core. Two things inflate 2.x bills in practice. Adaptive sampling’s target applies per instance, so a scale-out multiplies it. And teams that switched sampling off to “fix” their numbers often never switched it back on. The sampling guide covers both.

The 2.x telemetry processors that drop items do cut volume, but they skew counts, so keep them for items you never want to count, such as health checks.

Today: SDK 3.x and the Microsoft OpenTelemetry Distro

Both default to rate-limited sampling at five traces per second, with requests and dependencies sampled together. In .NET, logs that belong to an unsampled trace are dropped too (trace-based log sampling, on by default), which keeps log volume in line with trace volume; in Node.js and Python that behaviour is off by default.

Lowering the rate is one line. In the Microsoft OpenTelemetry Distro for .NET:

builder.UseMicrosoftOpenTelemetry(options =>
{
    options.Exporters = ExportTarget.AzureMonitor;
    options.AzureMonitor.TracesPerSecond = 2.0; // default is 5
});

Two defaults are worth a look on cost-sensitive apps. Standard metrics and performance counters are on by default (EnableStandardMetrics, EnablePerfCounters), and for billing Microsoft treats all OpenTelemetry metrics as Application Insights custom metrics. They are stored in the log store like other telemetry, and keeping their dimensions in the metric store (“With dimensions”) is a separately billed preview.

Cut the bill, in order

1. Fix the noisy source. Raise the minimum log level for chatty categories (logging levels shows where), stop logging handled exceptions in loops, and drop dependency calls nobody reads (health probes, cache pings).
2. Sample. Lower TracesPerSecond or switch to a fixed ratio. Counts stay correct because every kept row carries itemCount; the sampling and cost calculator turns a target GB per day into a percentage.
3. Move AppTraces to the Basic plan if you mostly read logs during incidents. It is the only Application Insights table that supports Basic ($0.50 per GB in East US), with a 30-day interactive query window and queries billed per GB scanned. No Application Insights table supports the Auxiliary plan.
4. Keep retention at 90 days unless you need more. Analytics retention beyond that costs $0.10 per GB per month; long-term retention, $0.02.
5. Consider a commitment tier once you reliably ingest 100 GB per day or more. Tiers save up to 30% over pay-as-you-go and run in 31-day commitment periods.
6. Set a daily cap as a fuse, not a budget. When it is reached, collection stops for the rest of a 24-hour period, data over the cap is still billed, and for a workspace-based resource the lower of the Application Insights and Log Analytics caps applies.

A worked example

An API handles enough traffic to send 5 million telemetry items a day at an average billed size of 1,200 bytes:

• 5,000,000 × 1,200 bytes = 6 GB per day, about 182.5 GB per month.
• Ingestion: (182.5 − 5 free) × $2.30 = $408.25 per month, if this is the only workload on the billing account.
• Retention: free for 90 days.

Sampling to 2 GB per day (keep a third) brings it to about 60.8 GB, or $128.42 per month. Find your own average item size by dividing a day’s billed bytes by its row count, then run the numbers in the calculator.

Troubleshooting a bill