---
title: "Optimize Application Observability costs | Grafana Cloud documentation"
description: "Understand what drives Application Observability costs and how to reduce host hours and telemetry usage without losing visibility."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# Optimize Application Observability costs

Application Observability bills on two dimensions: the **host hours** that send application telemetry, and the **telemetry** those hosts produce, such as metrics (active series), and traces, logs, and profiles (by volume). For the full billing model, refer to the [host-hours pricing](/docs/grafana-cloud/monitor-applications/application-observability/pricing/) documentation.

This guide explains what drives those costs and how to reduce them without losing visibility. Most savings come from controlling **metric cardinality**—the number of unique active series your telemetry generates—and from sending only the telemetry that has observability value.

> Tip
> 
> Start with the [Instrumentation Quality report](#use-the-instrumentation-quality-report) for a service. It automatically detects the most common and most expensive cost problems, such as high-cardinality span names, and links to the exact fix.

## What drives cost

Expand table

| Cost dimension         | Billed by                       | Primary levers                                                                                                                                                                                                                                                                                    |
|------------------------|---------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Host hours             | Hours each host sends telemetry | Correct [host identification](#control-host-hours); turn off telemetry from hosts you don’t need to observe                                                                                                                                                                                       |
| Metrics                | Active series                   | [Span name cardinality](#reduce-high-cardinality-span-names), [filter rules](#filter-out-spans-that-dont-add-value), [dimensions](#configure-metric-generation-dimensions), [instance label](#disable-the-instance-label-when-its-high-cardinality), [histogram buckets](#tune-histogram-buckets) |
| Traces, logs, profiles | GB ingested                     | [Sampling](#reduce-trace-log-and-profile-volume), filter rules                                                                                                                                                                                                                                    |

### Why cardinality matters most

Application Observability derives its RED (Rate, Errors, Duration) metrics from your span data. The number of active series those metrics produce is roughly the **product** of the distinct values of each label—`job` × `span_name` × `span_kind` × `status_code` × each histogram bucket, and so on. A single label with thousands of distinct values multiplies your series count and therefore your metrics bill.

The `span_name` label is the most common offender. Span names group operations into categories (for example, `GET /user/{id}`), not individual requests (for example, `GET /user/123`). When span names embed IDs, timestamps, or query strings, cardinality explodes.

## Reduce metric series

The following sections describe specific techniques to reduce active series and control metric costs.

### Reduce high-cardinality span names

High-cardinality span names drive avoidable metrics cost and prevent Application Observability from grouping operations meaningfully. Use generic patterns such as `GET /user/{id}` instead of specific values like `GET /user/123`.

The **Instrumentation Quality** report highlights offending span names and suggests low-cardinality replacements. To fix them at the source, rewrite span names with a transform processor on your collector. For collector configuration examples, refer to [Reduce high-cardinality span names](/docs/grafana-cloud/monitor-applications/application-observability/instrumentation-quality/#reduce-high-cardinality-span-names).

### Filter out spans that don’t add value

Some spans generate metrics and ingest volume without adding observability value—health checks, scrape endpoints, and static assets are common examples. Exclude them from metric generation with **filter rules**: in Application Observability, go to **Configuration**, select the **Metrics** tab, then **Filter rules**.

Common high-value exclusions:

- **Health check endpoints**—for example, span names matching `.*/healthz.*`
- **Metrics scrape endpoints**—for example, span names matching `.*/metrics.*`
- **Static assets**—for example, `http.url` matching `.*\.(png|jpg|jpeg|gif|css|js|ico|svg|woff|woff2)$`
- **Favicon and `robots.txt` requests**—automated, noise-only traffic

> Tip
> 
> Test filter rules on a subset of your data first to ensure you don’t accidentally exclude valuable telemetry.

Filtering these spans reduces both metric cardinality and trace volume.

### Configure metric generation dimensions

Each additional dimension (label) you generate metrics on multiplies the number of active series. In **Configuration > Metrics > Dimensions**, review which dimensions you configured for metric generation and keep only the labels you actually filter or group by in Application Observability. Removing an unused high-cardinality dimension can cut series counts substantially.

### Disable the instance label when it’s high cardinality

When Application Observability generates metrics from traces, it automatically adds an `instance` label. The instance label is useful in most environments and should stay enabled. However, in environments where instances are short-lived or numerous—so the label has high cardinality and isn’t useful—you can disable it in **Configuration > System** to reduce series as a cost-saving measure.

### Tune histogram buckets

Latency histograms emit one series per bucket boundary (`le`), so the number of buckets directly affects series count. Choose a bucket layout that matches the latency range you care about rather than keeping unnecessary fine-grained buckets across services. Coarser buckets mean fewer series.

If you use Grafana Cloud to generate span metrics from your traces, configure the bucket layout on the metric generation configuration page: in Application Observability, go to **Configuration**, select the **Metrics** tab, then **Histogram buckets**. If your metrics come from your collector or eBPF instead, set the buckets there.

#### Prefer native histograms

Where supported, prefer **native histograms** over classic histograms. A classic histogram emits a separate series for every bucket boundary (`le`) plus `_sum` and `_count`—10 or more series per histogram—whereas a native histogram represents the entire distribution as a single series, making it the most effective per-metric series reduction available.

> Caution
> 
> Don’t mix native and classic histograms within a single service. If you do, only the native histogram data appears. Refer to [Don’t mix histogram types in a single service](/docs/grafana-cloud/monitor-applications/application-observability/instrumentation-quality/#dont-mix-histogram-types-in-a-single-service).

### Avoid duplicate span metrics

If a service produces span metrics from both eBPF instrumentation (Beyla) and Grafana Cloud generation from traces, you pay for the same series twice and see erroneous data. Generate the metric from one source only.

To exclude eBPF or Beyla traces from Grafana Cloud metric generation, add the `span.metrics.skip=true` resource attribute to that trace data. With standard OpenTelemetry instrumentation, set `OTEL_RESOURCE_ATTRIBUTES="span.metrics.skip=true"`. Refer to [Avoid duplicate span metrics](/docs/grafana-cloud/monitor-applications/application-observability/instrumentation-quality/#avoid-duplicate-span-metrics).

## Reduce trace, log, and profile volume

Application Observability bills traces, logs, and profiles by ingested volume. To reduce them:

- **Sample your traces.** Head and tail sampling reduce the cost of processing and storing large trace volumes while keeping representative traces and edge cases. Refer to the [sampling](/docs/grafana-cloud/monitor-applications/application-observability/sampling/) documentation.
- **Apply filter rules.** Excluding noise-only spans (refer to [Filter out spans that don’t add value](#filter-out-spans-that-dont-add-value)) lowers trace volume as well as metric series.
- **Send telemetry only from services you need to observe.** Logs and profiles add value where you investigate. Scope collection to the services and environments that matter.

## Control host hours

Application Observability bills host hours per host that sends telemetry. The most common source of unexpected host-hours cost is **incorrect host identification**, which causes Grafana Cloud to count more hosts than you actually run.

> Note
> 
> For serverless environments (Container as a Service and Function as a Service, such as AWS Lambda), Application Observability bills on telemetry volume instead of host hours. In those environments, focus on the metric and volume levers in this guide rather than host hours.

### Common host identification issues

- **On Kubernetes**, set `k8s.node.name` on your telemetry. Without it, `host.name` resolves to the Pod name and every Pod counts as a separate host.
- **Behind a passthrough gateway**, set `override: false` on the gateway’s `resourcedetection` processor so it doesn’t overwrite the agent’s host attributes with its own identity, which leads to over-counting.
- **Verify host identification** for every environment that sends telemetry. The Instrumentation Quality report flags services with missing host identification.

For the full attribute priority and per-environment configuration, refer to the [host-hours pricing](/docs/grafana-cloud/monitor-applications/application-observability/pricing/) documentation.

## Use the Instrumentation Quality report

The **Instrumentation Quality** report finds cost problems for a specific service. Select the **Quality report** tab for a service. If there are issues, the tab shows how many. The report detects and links fixes for the issues most relevant to cost, including:

- High-cardinality span names
- Mixed histogram types
- Duplicate span metrics
- Missing host identification attributes

Refer to the [Instrumentation quality](/docs/grafana-cloud/monitor-applications/application-observability/instrumentation-quality/) documentation for the full list of checks.

## Cost optimization checklist

- Review the Instrumentation Quality report for your highest-traffic services.
- Generalize high-cardinality span names (`GET /user/{id}`, not `GET /user/123`).
- Add filter rules to exclude health checks, scrape endpoints, static assets, and crawler traffic.
- Remove metric generation dimensions you don’t filter or group by.
- Disable the `instance` label where it’s high cardinality and not useful.
- Right-size histogram buckets and prefer native histograms.
- Prevent duplicate span metrics when using both eBPF and trace-based generation.
- Enable trace sampling to control trace, log, and profile volume.
- Confirm you identify hosts correctly so you aren’t over-counting host hours.

## Disable Application Observability

If you no longer want to use Application Observability or incur any billing, you can disable it entirely. Note that you lose the visibility Application Observability provides. Refer to [Disable Application Observability in Grafana Cloud](/docs/grafana-cloud/monitor-applications/application-observability/pricing/#disable-application-observability-in-grafana-cloud).