Understanding Metrics Billing and Reducing Costs

Overview

Metrics are billed per sample ingested, at $0.10 per million samples (at one-month retention; longer retention raises the rate, see Pricing). A sample is one float value at one timestamp in one time series. There is no charge per time series, per unique metric, or per label. The glossary defines every term used on this page.

Cardinality is still the primary cost driver, and the reason is arithmetic rather than pricing:

total samples = active time series × export frequency

Every active series emits one sample per export interval, whether or not its value changed. So one series exporting every 30 seconds produces about 86,400 samples per month (about $0.0086). At the more common 60-second interval, about 43,200, or half that. Scale it up and 100,000 active series at a 30-second interval is roughly 8.6 billion samples per month, about $864.

That gives you exactly two levers: reduce the number of active series, or export less often. When this page says "reduce cardinality", it means reduce the series count so that fewer samples arrive on each interval.

Two consequences worth knowing up front:

Churn is free. A series replaced by a new one (a rollout giving each replacement pod a new k8s.pod.uid) sends the same number of samples. SigNoz does not bill per series, so churn adds no cost.
Dropping labels alone saves nothing. The same samples still arrive. Attributes have to be aggregated away so that the series collapse. See Volume control.

Histograms and summaries are the exceptions to "one data point, one sample". A classic histogram data point costs one sample per bucket (including the +Inf bucket), plus .count, which is always present, plus .sum, .min, and .max only when the SDK emits them. A summary data point costs one sample per quantile, plus .count and .sum.

How Attributes Affect Billing

Attributes affect the series count in one of two ways:

Identifying attributes: their values split otherwise-identical label sets into more series, so they multiply samples. If a metric has one label set and you add http.route, you get one series per route that actually appears, up to 10 series for 10 distinct routes, and that many data points per export interval instead of one. http.route, http.response.status_code, and host.name are all identifying.
Non-identifying attributes: their value is already determined by attributes present on the series, so they create zero new series and zero new samples. host.type is non-identifying when host.id is already there, because each host has exactly one type.

Resource attributes are not treated specially: they are part of series identity exactly like data point attributes, and they can be identifying or non-identifying in the same way. EC2 tags added by the AWS resource detector are a common example. They become part of series identity, but since each instance already has its own series, they add no series and no cost.

You can add as many non-identifying attributes as you like at no additional cost; metrics are not billed by label count or label size. Each new identifying attribute, however, multiplies your series count by its number of distinct values.

OpenTelemetry does not yet publish a canonical list of identifying attributes, though the project is moving toward distinguishing them. Until then, the practical test is the one above: would this attribute's values split an existing label set into more series?

Common Cost Drivers

High Cardinality Attributes

Avoid including random IDs or unique identifiers in your metric attributes. For example, instead of:

/bitcoin-mainnet-esplora/scripthash/20fd0a38027a2eeb14fd50fcbd94934f832bef4cc279958c30c72704338eb065/txs

Use a templated approach:

/bitcoin-mainnet-esplora/scripthash/${id}/txs

Histogram Metrics

Histogram metrics are particularly costly because:

Bucket configuration - Each bucket distribution creates a separate series. Optimize your bucket configuration based on your workload's latency patterns.
Cumulative nature - With cumulative histogram metrics, values continue to be sent even when there's no recent activity, especially problematic when combined with high-cardinality attributes like method names containing IDs. Switching to delta temporality avoids this. See Use Delta Temporality.

Cost Reduction Strategies

1. Use Delta Temporality

OpenTelemetry SDKs export metrics with cumulative temporality by default: on every export interval, the SDK re-sends the running total for every active series, even when nothing has changed since the last export. With delta temporality, synchronous instruments (Counter, Histogram) that record no measurements during an export interval export no data points at all for that interval, so idle series don't add billable samples.

PromQL does not read delta series. Before you switch a metric to delta, move any PromQL panel or alert on that metric to the Query Builder. A PromQL query on a delta metric keeps running and receives no new samples.

We recommend setting delta temporality in your application's SDK using the standard environment variable:

export OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE="delta"

This environment variable is supported by the OpenTelemetry SDKs for Java, Python, Go, JavaScript/Node.js, .NET, and Ruby. Some SDKs (such as Rust) configure temporality in code instead. See the application metrics guides for language-specific instructions.

Switching a metric to delta does not break the cumulative data that SigNoz already stored. The Query Builder reads the older cumulative points and the newer delta points together. See Temporality of Metrics.

The savings apply to synchronous instruments only. Observable (asynchronous) instruments emit a data point on every collection cycle regardless of temporality.

Deriving deltas at the OpenTelemetry Collector with the cumulativetodelta processor does not reduce costs. The SDK still exports the cumulative value on every interval even when nothing changed, and the processor converts each of those points into a zero-value delta point, which is still ingested and billed. To get the savings, set delta temporality in the SDK itself.

2. Remove or Template High-Cardinality Attributes

Replace unique IDs with templated values to reduce the number of unique time series being created.

3. Optimize Histogram Buckets

Reduce the number of buckets while maintaining meaningful data. See Configure Custom Buckets for more details.

4. Implement Sampling

Reduce the volume of metrics sent from your application. This directly reduces the number of data points ingested.

5. Review Attribute Necessity

Ensure all identifying attributes are essential for your monitoring needs. Remove any attributes that don't provide actionable insights.

6. Aggregate or Drop Metrics

Consider using the following techniques:

Aggregate away high-cardinality attributes - Use Metric Volume Control to aggregate away attributes you don't query by (like service.instance.id or k8s.pod.uid) at storage, reducing stored cardinality while keeping the remaining attributes correct and queryable. Collector-side alternatives like the MetricsTransform Processor only aggregate within a single batch and cannot aggregate resource attributes, so they don't work for data coming from multiple sources.
Drop entire metrics - See How to Drop and Filter OpenTelemetry Metrics to remove unnecessary metrics entirely.

Dropping metric labels or attributes does not reduce cardinality or costs. See Dropping Metric Labels for a detailed explanation of why this doesn't work and what to do instead.

Monitoring Your Costs

Use the Cost Meter to:

Monitor costs across different telemetry signals
Understand the cost breakdown and key contributors
Track metric datapoint ingestion over time
Set up alerts to notify you when costs exceed thresholds

Additional Resources

Comprehensive guide on cardinality
Cost Control: find which metrics drive your sample volume, then verify the reduction
Dropping Metric Labels: why dropping labels doesn't reduce costs
Cost Meter Overview: monitor your observability costs