Practice · Cardinality guardrails
How do you prevent a cardinality explosion?
Every unique combination of label values becomes its own time series, so an unbounded label like a user ID can create millions. A guardrail in code review, such as a linter that rejects high-cardinality labels, stops the explosion before it ships. Keep unbounded identifiers in logs and traces.
How to get started with Cardinality guardrails
- 1 Agree on which labels are allowed on metrics, and which identifiers belong only in logs and traces.
- 2 Add a lint or CI check that rejects unbounded labels like user ID, request ID, or raw URL.
- 3 Track active series per metric and alert when one grows sharply.
- 4 Normalize paths into route templates before using them as labels.
The common mistake
What is the most common mistake with Cardinality guardrails?
Adding user_id as a metric label because it would be handy in one query, and creating millions of series that slow every query and inflate the bill.
See it in action
Metrics Resolved calmly
The Label We Did Not Add
A pull request tried to add a user ID to a metric. A linter flagged it, a reviewer explained why, and an eight million series cardinality explosion quietly never happened.