Observability cost reduction in 2026: 6 billing rules that decide your bill

Summary. Grafana Cloud Application Observability moved to a new pricing model on 13 February 2026: $0.025 per host hour for new customers, plus $0.50 per 1,000 active series for metrics and $0.50 per GB for traces, logs and profiles, with no telemetry credits included. Customers who started before that date stay on $0.04 per host hour with 1.5 active series and 0.02 GB of traces included per host hour. Datadog, meanwhile, bills host-based products on a high watermark plan that discards the top 1% of hourly readings, roughly 7 of the 730 hours in a month, and charges $2 per profiled container above an allowance of 4 per host. Tom Wilkie, CTO at Grafana Labs, put the structural problem this way to The New Stack in January 2026: "The core issue is that the economics of observability have been upside-down for years. Costs grow linearly with telemetry volume, but the value doesn't." Six published billing rules decide most of what you pay. None of them are secret, and almost nobody reads them before signing.

The bill is a data-model problem

An observability invoice is the product of two things you control and one you do not. You control how much telemetry you emit and how it is shaped. You do not control the unit rate. Teams spend months renegotiating the rate and no time at all on the shape, which is backwards, because the shape is where the multipliers live.

A worked example on Grafana Cloud's published new-customer rates makes the proportions visible. Take 200 hosts running for a full month.

Host hours dominate at that shape. Change one variable, though, and the picture inverts: at 5 million active series instead of 500,000, the metrics line alone becomes $2,500 and starts rivalling the compute footprint it is supposed to describe. Cardinality is the multiplier, and cardinality is a code decision, not a procurement decision.

Rule 1: a custom metric is a name plus a host plus every tag

Datadog's billing documentation defines the unit precisely: "A custom metric is a single, unique combination of a metric name, host ID, and any tags." Under cardinality pricing, Datadog charges on the monthly average of unique custom metrics submitted per hour. Datadog also offers Metric Name pricing, which bills on metric names and datapoint volume instead.

That definition is the single most expensive sentence in observability. One metric with five tags of ten values each is not one metric. Across 200 hosts it is up to 200 x 10^5 unique series. Add a tag carrying a pod name, a request ID, a customer ID or a build SHA and the series count stops being bounded by anything an engineer can reason about.

The fix is boring and it works: enumerate every tag on every custom metric, classify each as bounded or unbounded, and move the unbounded ones out of metrics and into traces or logs where they belong. A request ID is not a metric dimension. It never was.

Teams already on Datadog should also check whether Metric Name pricing suits their shape better than cardinality pricing, because the two models reward opposite behaviours.

Rule 2: the high watermark plan throws away your top 1% of hours

Datadog offers two billing plans for host-based products including Infrastructure Monitoring, APM and Database Monitoring. On the high watermark plan, Datadog meters host count hourly, then bills on "the maximum count (high-water mark) of the lower 99% of those hourly readings, excluding the top 1% to reduce the impact of short usage spikes on your bill". On the hybrid monthly/hourly plan, you commit to a monthly minimum and pay an hourly rate above it.

Read the arithmetic. A 730-hour month has about 7 hours in that discarded top 1%. If your fleet doubles for a nightly batch window lasting 20 minutes, those hours fall inside the discard and cost nothing. If the same fleet doubles for eight hours every night, the peak sets your bill for the entire month.

Datadog's own guidance names the split: the high watermark plan "is well-suited to environments with stable usage throughout the month", while the hybrid plan "is well-suited to ephemeral environments, such as autoscaling fleets or short-lived workloads". Most teams are on whichever plan they were sold, not whichever plan matches their scaling profile. Plot your hourly host count for one month and the right answer is obvious in a single chart.

Rule 3: host attribution decides who gets counted at all

This is where the quiet overcharges live, and Grafana Cloud documents the mechanism openly.

Application Observability picks a host billing identifier from resource attributes in priority order and "uses the first match as the host's billing identifier": k8s.node.name first, then host.id, then grafana.host.id. If none of those attributes are present, "the service is not counted for host-hours billing" and the platform raises a configuration warning. Containers are explicitly excluded, "because they do not represent a full operating system instance".

Two failure modes follow directly, and both are configuration bugs rather than pricing disputes.

The first inflates your bill. A passthrough gateway running with the default override: true "causes the gateway to silently overwrite the agent's host attributes with its own identity, which leads to over-counting". Nothing in your dashboards changes. The invoice does.

The second distorts attribution. Inside Docker, the system detector's host.id means many containers collapse to a single host.id, so telemetry from separate workloads lands under one billing identity and your per-team chargeback becomes fiction.

On Kubernetes, the node is the billing identifier and host.id is ignored, so a workload with no k8s.node.name is not counted at all. Audit the attributes before you audit the spend.

Rule 4: serverless is billed on a different axis

Grafana Cloud does not apply host-hours billing to serverless. For Container as a Service and Function as a Service platforms including AWS Lambda, Google Cloud Functions and Azure Functions, "Application Observability uses telemetry-based billing instead of host-hours", and the documentation asks customers to contact support to confirm the environment is configured correctly.

That matters for any architecture that is part fleet and part functions. Moving a workload from EC2 to Lambda does not just change your compute bill, it changes which observability meter runs. Teams modelling a serverless migration routinely forget the second effect, then treat the surprise as a vendor problem.

Rule 5: span and log volume are two meters, not one

Datadog charges APM on two separate units. An ingested span is billed on "the total number of gigabytes of spans ingested into Datadog APM", while an indexed span is billed on the count of spans retained by retention filters. Logs work the same way: ingestion is charged per gigabyte submitted, and indexing is charged per million log events at the rate for the retention policy chosen.

The practical consequence is that sampling and retention are different levers with different economics. Tail sampling at the collector reduces ingested gigabytes. Retention filters reduce indexed spans. A team that tightens retention filters while shipping everything to the vendor has cut one bill and left the other untouched.

The collector is the control point for four of those six rows, which is the practical argument for an OpenTelemetry migration that has nothing to do with vendor ideology. Wilkie made the same point about where the use sits: "It's when you pair OTel with intelligent systems, which can reduce data by 80 to 90% while increasing the value of what remains, you start to flip the equation so that cost scales with value, not telemetry volume."

Treat the 80 to 90% figure as a vendor claim rather than a benchmark. The structural point underneath it stands regardless: filtering at the edge is cheaper than filtering after ingestion, because ingestion is the thing being metered.

Rule 6: the small meters add up

Three published rules that rarely appear in a cost review, and all three are easy to fix.

Datadog's Continuous Profiler allows up to four profiled containers per host at no charge, with containers above that priced at $2 per container. The allowance is aggregated across hosts, so an average of four containers per host across the fleet incurs nothing, but a lopsided distribution does.

CI Visibility bills on unique committers identified by git author email, and a committer counts towards billing after at least three commits in a month. Bot accounts, release automation and dependency-update services all have author emails. If a pipeline has no git repository or metadata, the username of whoever triggered it becomes the billable committer.

Real User Monitoring bills per thousand sessions, and a session "expires after either 15 minutes of inactivity, or 4 hours of continuous activity". Any product with long-lived idle tabs generates more billable sessions than the product team assumes.

What the published rates do not tell you

Two cautions before anyone builds a spreadsheet on the numbers above.

Grafana Cloud's Application Observability pricing page states "$0.50 per 1,000 active series" and "$0.50 per GB" without attaching a billing period to either figure, and it publishes no worked example, no free-tier allotment for Application Observability and no rounding rule for partial host hours. Widely circulated summaries of that page assert a 50 GB free allowance. That figure does not appear on the page. If your model depends on it, get it in writing from Grafana rather than from a comparison article.

Datadog's public documentation describes the units and the billing plans but not the rates, and ends by directing readers to contact sales or their customer success manager to discuss hourly pricing. So any published Datadog per-host number you find is either an old contract someone leaked or a competitor's estimate. Model the shape from the documented units, then get the rate from your own order form.

The pattern holds across the category: billing mechanics are documented, unit rates are negotiated. That asymmetry is precisely why fixing the shape beats chasing the rate.

A verification-first sequence

Do not start by asking for a discount. Start by finding out what you are actually being charged for.

Week one is measurement only. Export a month of hourly host counts, pull the top 50 custom metrics by series count, and list the resource attributes present on telemetry from every service. No changes.

Week two is attribution. Confirm the billing identifier resolves correctly on every deployment shape, check any gateway for the override: true default, and reconcile per-team chargeback against the identifiers actually being counted.

Week three is shape. Move unbounded tags out of metrics, put tail sampling in front of trace egress, and add a keep-list to log filtering. Measure the ingested-volume delta before touching retention.

Week four is contract. With the real hourly host profile in hand, choose between the high watermark and hybrid plans on evidence, and only then discuss rates.

Teams that run it in that order usually find that the changes in weeks two and three make the week-four conversation smaller. Teams that start in week four negotiate a discount on waste.

India-specific considerations

For Indian engineering teams and GCCs, three factors change the calculation.

Observability spend is billed in dollars while budgets are held in rupees, so a shape problem compounds with currency movement and lands as a variance nobody planned. That argues for controlling emitted volume rather than relying on a negotiated rate to hold.

Second, log content is a compliance surface, not just a cost line. Under the Digital Personal Data Protection Act 2023, personal data pushed into a third-party observability platform is still personal data, and most accidental leakage happens through debug logs and high-cardinality tags carrying user identifiers. The same collector-side redaction that reduces ingested gigabytes reduces that exposure, so the cost project and the privacy project are the same project. Applications should be designed aligned with DPDP requirements from the collector configuration outward, not retrofitted after an audit finding.

Third, many Indian teams run split estates: a managed Kubernetes cluster with a self-hosted fleet alongside it, plus serverless functions. That is exactly the shape where host attribution breaks and where the serverless billing exception in rule 4 applies. Audit each estate separately.

For the wider spend picture these decisions sit inside, see how Indian teams cut cloud spend with FinOps, the specifics of capping LLM observability costs on Datadog, and the way cloud egress fees change an AI inference bill. Teams looking for continuous ownership rather than a one-off exercise should look at our cloud FinOps managed service.

What we build, and who this is for

This engagement suits teams whose observability bill is growing faster than their traffic, teams migrating from proprietary agents to OpenTelemetry, and teams who need per-team chargeback that survives scrutiny.

The work is concrete. We audit metric cardinality and produce a ranked list of series-generating tags with an owner against each. We instrument or re-instrument services on OpenTelemetry and stand up a collector layer that does filtering, redaction and tail sampling before egress. We verify host attribution across every deployment shape so the billing identifier resolves the way your chargeback model assumes. We model your hourly host profile against both published billing plans. And we leave behind dashboards and alerts that survive the data reduction, which is the part most cost exercises skip.

We do not promise a percentage. Anyone quoting one before seeing your cardinality profile is guessing, and the honest answer is that the size of the win depends entirely on how many unbounded tags are already in your code.

FAQ

How eCorpIT can help

eCorpIT designs and runs observability cost programmes as engineering work rather than procurement work: cardinality audits, OpenTelemetry instrumentation, a collector layer that filters and redacts before egress, and host-attribution verification across every deployment shape you run. We are a CMMI Level 5 and ISO 27001:2022 certified organisation with senior engineering teams and partnerships with AWS, Microsoft and Google. We design telemetry pipelines aligned with Digital Personal Data Protection Act 2023 requirements so the cost work and the privacy work land together. If your observability bill is outgrowing your traffic, contact us for a cardinality and attribution assessment against your own data.

References

1. Datadog documentation, pricing and billing plans

1. Grafana Cloud documentation, Application Observability host-hours pricing

1. The New Stack, can OpenTelemetry save observability in 2026 (1 January 2026, by B. Cameron Gain; Chronosphere is a sponsor of The New Stack)

1. Datadog documentation, custom metrics billing

1. Datadog documentation, metric name pricing

1. Datadog documentation, log management billing

1. Datadog documentation, APM tracing and profiler billing

1. Datadog documentation, trace retention filters

1. Datadog documentation, trace ingestion controls

1. Grafana Cloud documentation, understand metrics usage and cost

1. Grafana Cloud documentation, reduce Grafana Cloud Logs costs

1. Grafana Cloud documentation, Application Observability invoice

1. Datadog pricing page

1. Grafana pricing page

Last updated: 7 August 2026.