Because each unique tag combination becomes a separate billable time series. A single metric can explode when teams add dimensions such as user ID, endpoint, or pod name, especially in containerised systems where labels churn constantly. The cost grows multiplicatively, so the right fix is to govern tags before they are exported.
Why tag cardinality turns observability into a billing multiplier
High-cardinality tags are expensive because observability vendors usually bill on the number of distinct time series, not just on the metric name. Every new combination of tag values creates another series to store, index, query, and retain, so a metric that looked harmless at low scale can become a cost driver once teams add high-variance dimensions.
That is why user IDs, request IDs, pod names, container hashes, and full endpoint paths are the usual culprits. They produce a much larger series surface than stable labels such as service, region, or environment, so the same metric can move from a compact signal to a large and expensive dataset as soon as the label space starts to churn.
The practical issue is not just price. High-cardinality data also makes queries slower, dashboards noisier, and retention choices harsher because the platform has to manage far more distinct series. In containerised environments this grows even faster, since short-lived workloads constantly create and retire labels, which multiplies the number of distinct combinations the platform must track.
What actually changes when labels become high-cardinality
Cardinality changes the economics of telemetry because it changes the unit of storage and computation. Instead of one metric representing one operational signal, the platform has to maintain many series that all represent slices of that signal. The more dimensions you attach, the more those slices multiply, and the more every downstream function, from ingest to query to retention, gets more expensive.
That multiplicative effect is why observability teams often talk about controlling tags before export. Once a label has been emitted at scale, the cost is already being incurred in storage and indexing, and dropping it later does not erase the upstream growth already caused by historic series creation. Governance has to happen at the instrumentation boundary, not after the bill arrives.
Stable, low-variance labels usually preserve the operational value of the metric without exploding the series count. The best practice is to ask whether a tag will help answer a repeated operational question. If it only helps isolate an individual request, user, or ephemeral pod, it may be useful for debugging but too expensive for default production telemetry.
How teams keep observability useful without runaway spend
The control is to separate diagnostic detail from baseline metrics. Keep low-cardinality dimensions on the metric path, and push highly variable identifiers into logs, traces, sampled events, or short-lived debug collection where they are needed, rather than promoting them into every metric series.
Teams should also define an explicit tag allowlist and review it as part of release governance. A safe rule is to treat each new label as a change to the metric schema, because that is exactly what it is in cost and scale terms. If a tag cannot justify its operational value, it should not be allowed to enter the default metric stream.
Container metadata deserves special handling. Orchestration labels, pod names, replica IDs, and deployment hashes often look convenient, but they can create a near-continuous stream of new series as workloads roll, autoscale, and restart. That is the point where observability stops being a shared control plane and starts becoming an uncontrolled meter.
Risk and Threat Considerations
High-cardinality tagging is a financial and operational exposure because a small instrumentation change can create a large and persistent bill shock. In shared platforms, the same pattern can also degrade detection quality and availability by overwhelming ingestion or query performance, especially when ephemeral infrastructure keeps generating new series.
Failure mechanism: New or unstable tag values create unique metric series at scale, which multiplies ingestion, indexing, storage, and query work faster than teams expect.
Impact: Costs spike, dashboards slow down, retention gets constrained, and noisy telemetry can mask the signals operators actually need during incidents.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Controls telemetry volume and log data quality, which relates to observability cost growth from excessive dimensions. |
| Recommendation — Review telemetry schemas and limit high-variance fields before they enter production observability pipelines. | ||
| NIST CSF 2.0 | GV.PO-01 — Policy for Cybersecurity Risk Management | Observability tag governance is a policy decision that constrains expensive telemetry growth before deployment. |
| Recommendation — Define and enforce a policy for allowable metric tags and cardinality thresholds. | ||
| ISO/IEC 27001:2022 | A.8.16 — Monitoring activities | Monitoring design must balance visibility with controlled data volume and system performance. |
| Recommendation — Set review criteria for telemetry fields that can expand monitoring cost or degrade performance. | ||
Practitioner Guidance
What to prioritise: Put a hard approval process around any tag that can vary per user, request, pod, container, or endpoint parameter. Those are the dimensions most likely to turn a stable metric into an expensive series factory.
What to verify: Before trusting a new metric, confirm how many unique series it can produce in production-like traffic, not just in staging. If the answer is unknown, treat the metric as an unreviewed cost risk.
Common mistake: Teams often assume that “more detail” automatically means “better observability.” In practice, the better design is the one that preserves the question you need to answer while keeping the series count bounded.
Practitioner takeaway: Treat tag design as part of telemetry governance, because the cheapest time to prevent a cardinality explosion is before the label is exported, not after the bill or the outage.
Related resources from NHI Mgmt Group
- Why do high-cardinality metric tags create such a cost problem?
- Why does high cardinality create cost and performance risk in observability platforms?
- Why do leaked API tokens create such high cost risk in AI application platforms?
- Why do device-management platforms create such large blast radius risk?