High cardinality describes metric labels or fields that generate a very large number of unique values. It is not inherently wrong, but it becomes a problem when dynamic identifiers, user specific paths, or instance IDs create excessive time series and drive cost and performance issues.
What high cardinality means in observability data
High cardinality is a property of telemetry fields, especially metric labels, where the number of distinct values grows very large. The practical issue is not the label itself, but the volume of unique combinations it creates. Once cardinality rises, the telemetry system must store, index, aggregate, and query far more series than intended.
In observability platforms, cardinality is a data-shape problem as much as a monitoring problem. A field such as HTTP path, user ID, request ID, container name, or pod UID can explode series count when it varies on every request or deployment. That makes the metric less reusable, more expensive to retain, and harder to query at useful speed.
Why high cardinality becomes expensive
The cost impact comes from series multiplication. Each unique label set usually creates a separate time series, so a single metric can become thousands or millions of series when a dynamic value is included. Storage, ingestion, retention, and indexing all get heavier, and dashboards may slow down or fail to render within acceptable time.
High cardinality also degrades the signal quality of metrics. When the label space is too wide, aggregation becomes less meaningful because the data is fragmented across too many dimensions. That can hide trends, make outliers harder to spot, and reduce the practical value of alerts.
Common sources of cardinality growth
The most common causes are dynamic or unbounded values. Examples include user names, email addresses, full request URLs, per-instance identifiers, trace IDs, session IDs, and other values that change frequently by design. These fields are often useful in logs or traces, but they are usually too variable for metric labels.
Environment design can amplify the problem. Ephemeral infrastructure, autoscaling, per-tenant sharding, or highly dynamic service discovery can all increase the number of unique dimensions in telemetry. Even a sensible metric can become high cardinality if it is combined with a rapidly changing deployment or routing pattern.
How to think about it in practice
High cardinality is not automatically wrong. Some use cases need detailed segmentation, and not every large label space is a defect. The key question is whether the added uniqueness produces actionable insight at an acceptable cost. If a field is best used for search, correlation, or forensic detail, it often belongs in logs or traces rather than in a metric label.
A useful rule is to prefer bounded, low-variance dimensions in metrics, and reserve highly variable identifiers for richer telemetry types. That keeps dashboards stable, preserves query performance, and limits the risk that monitoring costs scale faster than the system being observed.
Risk and Threat Considerations
High cardinality creates operational risk because a monitoring system can become expensive, slow, or noisy long before teams realise the root cause. It also creates a denial-of-observability problem when dashboards or alert pipelines are overwhelmed by a field that was never meant to vary at that scale.
Failure mechanism: Excessive unique label values multiply time series, increase query fan-out, and push telemetry backends into expensive storage and aggregation patterns that are hard to control once deployed.
Impact: Teams may reduce retention, throttle ingestion, miss alerts, or disable useful metrics altogether, which weakens detection, troubleshooting, and service reliability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management | High cardinality can raise observability service dependency and cost risk. |
| ID.AM-03 — Asset inventory is maintained | Cardinality issues depend on knowing which metrics and labels are being produced. | |
| PR.PS-01 — Configuration Management | Metric label design is a configuration concern that affects system performance and cost. | |
| Recommendation — Define telemetry volume limits and review observability vendor capacity assumptions. Inventory metric sources and label sets so you can spot unbounded dimensions early. Apply configuration controls to restrict high-variance labels in production telemetry. | ||
| NIST SP 800-53 Rev 5 | AU-3 — Content of Audit Records | Telemetry design influences which event attributes are collected and at what scale. |
| CM-2 — Baseline Configuration | Metric schema and label policy are part of a controlled baseline for observability. | |
| Recommendation — Limit collected fields to those needed for monitoring, audit, and investigation. Baseline approved metric labels and reject uncontrolled additions. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Observability data volume and structure affect logging and monitoring effectiveness. |
| Recommendation — Standardise telemetry fields so monitoring remains usable and cost controlled. | ||
Practitioner Guidance
What to watch for: Review metric design whenever a label can be derived from user input, resource IDs, paths, or other unbounded values. If a field can grow with traffic volume, tenant count, or deployment churn, treat it as a cardinality risk before it reaches production scale.
Governance implication: Observability owners should define which dimensions are acceptable in metrics and which belong in logs or traces instead. That decision keeps telemetry predictable and prevents cost or performance surprises from becoming an ongoing platform problem.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org