Cardinality

Overview

Cardinality is the number of distinct tag values that actually appear for a single tag key attached to your monitoring data. If <code>env</code> has 3 possibilities, production, staging, and development, the cardinality is 3; if you make the user ID a tag, it grows with the number of users. The troublesome part is that this number affects the total in a multiplicative way across tag keys. The decision to add a tag whose values are finite and the decision to add one whose values are unbounded look like the same amount of work but have completely different outcomes. Heavy dashboards, quota consumption, and hard-to-read bills usually trace back to this one point. When deciding whether to add a tag, the practical order is to first estimate how many distinct values it could grow to, rather than whether it is convenient.

How many distinct values a single tag key has

Datadog's official glossary explains cardinality in the sense of "for a given metric, the number of tag values tied to a single tag key." The key point is that what is counted is per tag key. If the key env shows 3 values, production, staging, and development, the cardinality of env is 3. If region has 5 locations it is 5, and if user_id has as many values as registered users, that number is the cardinality as it stands. Once you get used to counting this way, conversations about monitoring design become concrete. Saying "adding tags makes things heavy" does not point to the cause. What makes things heavy is not the number of tags but the result of multiplying the distinct values of each key together. That is exactly why the idea of deciding, for each key, an upper limit of "how many distinct values this key may grow to" is effective. Cardinality is the name of an observed phenomenon, but in practice decisions come faster if you treat it as a budget you allocate. When designing Tags, writing out the number of distinct values per key rather than a list of keys makes the differences that will matter later visible from the start.

It grows by multiplication, not addition

Cardinality becomes a problem because it works as a factor in a multiplication. If a single metric carries 3 tags whose distinct values number 20, 3, and 40, the combinations come to 2,400. The moment you add one more tag with an unbounded number of distinct values, the total moves from a number you can estimate to one you cannot.

The last line is the shape of real incidents. Datadog's official documentation explicitly warns that putting unbounded values such as epoch timestamps, user IDs, or request IDs into tags makes metrics grow without limit. The problem is that to the person who added it, it looks like "I just added one tag for an investigation," when what grows is not the one tag added but the total, multiplied against the 2,400 combinations that already existed. Even with bounded values, the fact that it is multiplication does not change. Add one tag with 5 distinct values, and by simple arithmetic the total becomes 5 times larger. Conversely, cutting also works multiplicatively. When you want to reduce the number of Custom Metrics, consolidating metric names does not move the total because the number of names is not the factor; the distinct tag values are.

Separating what you send from what you can search

The multiplicative nature itself cannot be changed, but Datadog has a mechanism for narrowing what gets multiplied. According to the official documentation as of August 2026, Metrics without Limits is a feature that separates ingestion of custom metrics from indexing; sending itself continues as before, and the user chooses which of those tags to make usable in search, graphs, and monitors. There are 2 ways to specify this. An allowlist approach that enumerates the tags to use, and an exclusion list approach that names the tags to remove; in the API, setting exclude_tags_mode to true gives you the latter. The configuration screen for a single metric is built so that a recommended allowlist, based on the tags actually queried over the past 30 days, is pre-filled. For metrics that have never been used in a query, you can also choose to empty the allowlist and stop indexing. Operational cautions are also stated officially. First, the metric's type must be set before you manage its tags. Next, the default for bulk configuration is "allow all tags," and it overwrites configurations built up individually. And if the estimate display shows the indexed volume as larger than the ingested volume, that configuration should not be saved. On the usage screen these 2 volumes are shown separately as Ingested and Indexed, so the effect of a configuration change can be confirmed with numbers rather than by feel. The relationship to billing depends on the plan you have contracted. The official documentation explains that under cardinality-based pricing, only configured metrics count toward ingested volume, and unconfigured metrics are subject only to the indexed volume. Under metric-name-based pricing, on the other hand, every data point you send counts toward ingested volume regardless of configuration. Starting reduction work without knowing which plan you are on ends with the number you worked hard on not moving.

What happens if you use it without estimating, and what it gets confused with

Monitoring without the perspective of cardinality ends up deciding whether to add a tag solely on "would it be convenient to have." The result shows up in 2 forms. One is heavy dashboards and searches; the other is hard-to-read numbers arriving at the end of the month. Since the causes of both are scattered throughout the configuration, finding them afterward takes time. If you estimate cardinality up front, decisions finish in a minute, in the form of "this tag has 6 values, so include it" and "this one is proportional to the number of users, so leave it out." A prominent confusion is thinking that the cause of growing volume is the frequency of sending. Lowering the frequency does not reduce the number of combinations, so countermeasures in this direction have almost no effect. Another is thinking that a tag removed from the configuration also disappears from past data. The effect of changing the indexing configuration applies from then on; the history of series already retained is not rewritten retroactively. It is nearly the same idea as cardinality in the database world (the number of distinct values in a column), but in Datadog the subject is the tag key, and the difference is that it is directly tied to cost and display speed. Lining up neighboring terms brings out the outline. A Tag is the marker itself, cardinality is the number of distinct values that marker takes, and a Custom Metric is the unit when each combination is counted as one. A Metric is the higher-level concept of a numeric time series, and cardinality refers to the spread of the attributes attached to it. In areas such as Infrastructure Monitoring, where tags are attached automatically per host, keys increase even where the user is not paying attention, so a habit of periodically checking the number of distinct values pays off. The primary sources are Datadog's official documentation, Glossary and Metrics without Limits.