Application Insights charges on the volume of telemetry ingested into the Log Analytics workspace behind it, which means a high traffic application emitting a request, dependency, and trace record on every call can drive a large, fast growing bill. Sampling is the lever that breaks the link between traffic and cost: it keeps a statistically representative subset of telemetry and discards the rest, while storing an item count on each retained record so aggregate metrics are scaled back up and stay accurate. Configured correctly you lose individual records for deep trace inspection, not the statistical picture your dashboards and alerts depend on. The goal is to ingest the signal you actually use and stop paying to store millions of near identical success records you will never open.
Here are the sampling modes, what each is for, and how to cut cost without losing the data you rely on.
Why does Application Insights get expensive?
The cost model is volume based. Every telemetry item, requests, dependencies, traces, exceptions, and custom events, is ingested into a Log Analytics workspace and billed per gigabyte. On a low traffic service this is trivial. On a high throughput application it is not, because the telemetry volume scales with request count, and most of that volume is repetitive success telemetry: thousands of identical healthy requests for every interesting failure. You end up paying to ingest and retain a vast amount of data that confirms the system is working, when the value is concentrated in the small fraction that shows it is not. Sampling exists precisely to keep the informative subset and drop the redundant bulk.
What are the sampling modes?
Application Insights offers three approaches, applied at different points in the pipeline. Adaptive sampling is the SDK default and the right starting point for most: it automatically varies the share of telemetry kept to hold ingestion near a target rate, dialling retention down during spikes and up during quiet periods, with no manual tuning. Fixed rate sampling keeps a constant, configured percentage of telemetry and is useful when you want a predictable, consistent rate across services, particularly to keep client and server telemetry correlated. Ingestion sampling runs in the service itself rather than the SDK, sampling telemetry as it arrives when SDK level sampling is not available, for example from sources that do not support it. Adaptive and fixed rate act before data leaves the application, so they also reduce network egress; ingestion sampling acts at the workspace and reduces stored volume only.
Does sampling distort your metrics?
Not when it is configured properly, and this is the objection that keeps teams overpaying. When Application Insights samples, it records the sampling rate as an item count on each retained record. Aggregate calculations, request rates, dependency call counts, failure rates, then multiply the retained records back up by that count, so the totals and rates you see in metrics and alerts reflect the full traffic, not just the sampled slice. What you genuinely lose is some individual records, which matters only when you need to inspect a specific trace that happened to be sampled out. For aggregate health, capacity, and failure monitoring, the picture is intact. The practical rule is to sample aggressively for high volume success telemetry and protect the records you need for forensic depth, which the next section covers.
A European SaaS company ran a high traffic API with full telemetry on every call, and Application Insights ingestion had grown into one of the larger Azure Monitor lines on its bill, dominated by repetitive successful request and dependency records. Enabling adaptive sampling with a sensible target rate cut the ingested volume substantially during normal and peak traffic, while the item count mechanism kept request rates and failure counts accurate on every dashboard and alert. The team retained full fidelity on exceptions and a sampled but representative stream of successful calls. Ingestion cost on the application fell by more than half with no loss of the metrics operations relied on, and no change to the alerts that page the on call team. The figures are verified against billing data and anonymised.
How do you sample without losing what matters?
Treat sampling as a policy, not a single switch. Start with adaptive sampling as the default and set the target rate against how much telemetry you actually query, not the maximum the SDK will emit. Protect the high value, low volume telemetry, exceptions and key custom events, from aggressive sampling so failures are never dropped, while letting routine successful requests sample down hard. Keep client and server sampling consistent where you rely on correlated traces. Pair sampling with a sensible Log Analytics retention period, since paying to keep sampled data for longer than you investigate it is its own waste, and consider the basic logs and archive tiers for data you must keep but rarely query. Sampling controls what enters the workspace; retention controls how long you pay to keep it, and both belong in the same review.
Frequently asked questions
Why does Application Insights get expensive?
What is adaptive sampling in Application Insights?
Does sampling distort your metrics?
Tune your Azure observability cost with us
We tune Application Insights sampling and Log Analytics retention across Azure estates, so observability cost tracks the signal you use rather than the traffic you serve. We take zero provider commissions and answer only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on either a Fixed Fee or a no risk Gainshare basis. Book a strategy call to scope it, and follow more in The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.