Datadog Custom Metrics and Cardinality: How Costs Grow

Short answer: why can Datadog custom metrics grow so quickly?

A metric name does not necessarily represent one billable custom metric.

Under Datadog's Cardinality Pricing model, a custom metric is identified by a unique combination of metric name, host and tag values. If the same metric is emitted across many combinations of service, environment, region, route, pod, customer_id or other dimensions, those combinations can create many distinct custom metrics. Datadog measures those unique custom metrics hourly and bases monthly usage on the average hourly count.

That produces the core mechanism:

instrumentation → metric → dimensions → distinct emitted combinations → custom-metric cardinality → Datadog usage → cost exposure

But there is an important commercial qualification: Datadog also offers Metric Name Pricing, which bills custom metrics based on unique metric names and the datapoint volume those names produce rather than directly billing unique metric contexts. Before converting cardinality into money, establish which pricing model applies to the organization.

The optimization objective should therefore not be "remove as many tags as possible."

It should be:

Reduce cardinality without removing dimensions that change operational decisions.

The cardinality model in one table

What Datadog metric cardinality actually means

Three related concepts are often described simply as "cardinality," although they are not identical.

Tag cardinality

Datadog defines tag cardinality as the number of values associated with a tag key for a metric. A tag such as:

environment:production
environment:staging
environment:development

has very low cardinality.

A tag such as:

customer_id:183821
customer_id:183822
customer_id:183823
...

can have very high cardinality because its value population may grow with the number of customers.

Metric contexts under Datadog Cardinality Pricing

For custom-metric billing under Cardinality Pricing, the important quantity is not the number of values on one tag in isolation. It is the number of unique combinations produced by the metric name, host and its tags.

For example:

api.request.duration
service:orders
environment:prod
region:eu-west

and:

api.request.duration
service:orders
environment:prod
region:us-east

represent different combinations.

Add route, pod_name, customer_id or another dimension and additional combinations can appear.

Time series in Prometheus and attributes in OpenTelemetry

Prometheus describes each unique combination of label key-value pairs as another time series. OpenTelemetry describes metric cardinality in terms of unique attribute combinations tracked for a metric stream. These ideas are closely related to Datadog cardinality, but the terminology and backend accounting rules should not be treated as identical.

That distinction becomes important when telemetry crosses systems:

Prometheus labels → OpenMetrics → Datadog tags

or:

OpenTelemetry attributes → OTLP → Datadog tags

A perfectly reasonable dimension upstream can still become commercially significant once it participates in the dimensional model used by the destination backend.

How dimensions create cardinality

Consider a hypothetical platform emitting one application metric with these dimensions:

• 12 services
• 3 environments
• 4 regions
• 50 normalized routes

The theoretical Cartesian product is:

12 × 3 × 4 × 50 = 7,200

That does not mean Datadog necessarily receives 7,200 distinct contexts.

Perhaps some services operate in one region only. Some routes may exist only in production. Some service-route combinations may never occur.

If only 2,430 combinations actually emit datapoints during the period being examined, the observed dimensionality is 2,430 rather than 7,200.

The Cartesian product is therefore best understood as a risk model, not a billing calculation.

Now add:

customer_id

with 20,000 possible values.

The theoretical combination space becomes enormous, but again, not every customer will use every service, region and route.

The dangerous part is that even a small subset of those combinations may still produce tens or hundreds of thousands of active series.

Prometheus explicitly warns that every unique labelset creates an additional time series and advises against labels containing unbounded sets such as user IDs or email addresses.

The correct reasoning is therefore:

Possible combinations explain the explosion mechanism. Observed combinations determine the real cardinality.

Do not multiply every possible value and call the result your Datadog bill.

But do not ignore the multiplication mechanism either.

Cardinality Pricing and Metric Name Pricing are different cost models

Before interpreting a cardinality finding financially, identify the organization's Datadog pricing model.

Cardinality Pricing

Datadog's current documentation defines a custom metric as a unique combination of metric name, host ID and tags. Datadog records the unique custom metrics submitted each hour, and the monthly billable custom-metric count is based on the average hourly usage.

This detail matters.

The relevant quantity is not simply:

"How many different combinations existed at any moment during the entire month?"

A rapidly changing identifier can create many contexts over time, but the billing model is based on Datadog's documented hourly measurement and monthly averaging mechanics.

Under this model, reducing unnecessary active contexts can directly reduce the cardinality component of custom-metric usage.

Metric Name Pricing

Datadog also documents Metric Name Pricing, which bills custom metrics based on the number of unique metric names submitted and the volume of datapoints generated by those names.

Cardinality is still operationally relevant: more active dimensional combinations can cause more datapoints to be produced.

But the financial model is no longer:

number of unique contexts × unit price

Datadog's current Metrics experience reflects this difference. For Metric Name Pricing organizations, tag-management interfaces estimate the effect of changes on point volume rather than cardinality volume, and metric details expose ingested and indexed point volume accordingly.

The practical rule is simple:

Never turn a cardinality finding into a savings estimate before confirming the pricing model and the executed contract.

A special case: distribution metrics

Distribution metrics need separate attention when modeling custom-metric usage.

Under Datadog's cardinality-based billing documentation, distributions produce server-side aggregation metrics, including count, sum, minimum, maximum and average. Enabling percentile aggregations can increase the number of custom metrics associated with each tag combination further.

That means an apparently simple statement such as:

"This metric has 10,000 tag combinations."

may still be insufficient to model usage correctly if the metric is a distribution with additional aggregations enabled.

For an enterprise cost review, distribution metrics should therefore be inspected using Datadog's current billing rules rather than treated as ordinary gauges or counters.

Why cardinality can grow faster than traffic

Traffic and metric cardinality measure different things.

Imagine a platform processing ten million requests per day in January and the same ten million requests per day six months later.

Traffic is flat.

During those six months, however:

• the Kubernetes estate grows from 200 to 700 active pods;
• several teams expose additional Prometheus labels;
• an instrumentation update adds customer_id;
• URLs that were previously normalized begin including resource identifiers;
• a second region is deployed;
• short-lived jobs create new workload identities;
• more metadata is propagated through OpenTelemetry.

The number of requests has not changed.

The number of distinct dimensional identities represented by the metrics has.

OpenTelemetry defines metric cardinality around unique attribute combinations, not request volume, and its SDK maintains aggregation state for those combinations subject to configured cardinality limits.

This is why a custom-metrics curve can diverge sharply from a request-volume or host-count curve.

A useful diagnostic question is:

What new values or combinations appeared in the dimensional model?

rather than only:

"Did the application process more traffic?"

The main sources of high-cardinality metrics

The most dangerous metric dimensions generally share one property:

their value population grows with individual entities, events or ephemeral resources rather than with stable operational categories.

Request-level identifiers

Examples include:

request_id
trace_id
span_id
session_id

These identifiers are excellent for locating a specific event.

They are usually poor metric dimensions because metrics are designed to aggregate repeated observations.

A trace ID that is effectively unique for every request turns an aggregate latency measurement into many separately identified observations.

When individual-request diagnosis is the requirement, traces and logs are generally better places for that identity. OpenMetrics itself uses exemplars as a mechanism for referencing traces without making trace IDs part of the metric's main labelset.

Business entity identifiers

Examples include:

customer_id
order_id
transaction_id
account_id

These are not universally wrong.

Suppose an enterprise SaaS provider has twenty strategic tenants with contractual per-tenant SLOs. A deliberately bounded tenant dimension on a specific reliability metric may be operationally justified.

That is very different from adding every customer ID to every application metric.

The useful distinction is:

bounded operational segmentation

versus:

entity-level telemetry disguised as a metric dimension.

Raw URLs

These values:

/orders/182736
/orders/182737
/orders/182738

represent different resources but often the same operational route:

/orders/{order_id}

For throughput, latency and error metrics, the normalized route is usually the dimension that changes an operational decision.

The individual resource identifier can remain available in traces or logs.

Ephemeral infrastructure identity

Examples include:

pod_name
container_id
task_id
job_instance_id

These identifiers may be useful when diagnosing one running instance.

But if an application-level metric is primarily used to understand service latency, error rate or throughput, retaining every ephemeral instance identity can create a large dimensional surface without improving the questions the metric is intended to answer.

The correct answer is not "never use pod names."

It is:

Use ephemeral identity where instance-level analysis changes an operational decision, rather than attaching it indiscriminately to every metric.

Kubernetes: rich metadata can become metric cardinality

Kubernetes is not inherently a cardinality problem.

It simply creates a large amount of useful metadata, and Datadog provides several ways of attaching that metadata to telemetry.

The Datadog Agent can derive tags from Kubernetes labels and annotations. Datadog also exposes tag-cardinality controls that determine which classes of container and orchestrator tags are added to metrics.

Datadog currently distinguishes cardinality configuration for metrics collected by checks and metrics submitted through DogStatsD using settings such as:

DD_CHECKS_TAG_CARDINALITY
DD_DOGSTATSD_TAG_CARDINALITY

with cardinality levels including low, orchestrator and high. Datadog's documentation identifies container_id as an example of a high-cardinality container-level tag and warns that tag cardinality can affect the number of emitted metrics and therefore billing.

The architectural question should therefore be asked per metric class.

A service-level latency metric may need:

environment
service
region
cluster
deployment
normalized_route

but not necessarily:

container_id

An infrastructure troubleshooting metric may make a different trade-off.

The mistake is not Kubernetes metadata.

The mistake is treating every available metadata field as a universally useful metric dimension.

Prometheus and OpenMetrics: migrating labels also migrates a cardinality model

Prometheus uses labels extensively, and every unique labelset represents another time series. Its documentation explicitly warns against unbounded dimensions such as user IDs.

When Datadog collects metrics using its generic OpenMetrics integration, those metrics are forwarded to Datadog as custom metrics. Datadog states the same for metrics collected through its generic Prometheus/OpenMetrics collection paths.

That creates an important migration implication.

Moving Prometheus telemetry into Datadog does not merely import:

metric names

It can also import:

the existing label model

A Prometheus metric designed with:

method
status
service

may translate efficiently.

A metric designed with:

user_id
raw_path
pod
session
transaction_id

carries a very different dimensional profile.

Before enabling broad Prometheus/OpenMetrics collection, inspect the labelsets of the metrics being imported, not merely the number of metric names.

OpenTelemetry: attributes make cardinality portable

OpenTelemetry metric datapoints can carry attributes, and the number of unique attribute combinations constitutes metric cardinality.

Current OpenTelemetry documentation describes a default SDK cardinality limit of 2,000 for a metric stream. When the limit is reached, additional combinations are aggregated into an overflow point identified by:

otel.metric.overflow=true

rather than creating unlimited additional points.

This is an important safety mechanism, but it is not a replacement for dimension design.

Once a metric is overflowing, some segmentation has already been lost.

OpenTelemetry's semantic-convention rules also require metric attributes that may have high cardinality to be defined as Opt-In, reflecting the principle that potentially unbounded dimensions should not silently become default metric dimensions.

Metric attributes versus resource attributes

There is another nuance when OpenTelemetry metrics reach Datadog.

Metric attributes naturally participate in the datapoint's dimensional identity.

Resource attributes are different: whether they become Datadog metric tags depends on the ingestion and mapping configuration. Datadog's semantic mapping documents default mappings for selected OpenTelemetry resource attributes, while some OTLP ingestion configurations can transform broader sets of resource attributes into metric labels and therefore Datadog tags.

Consequently, an OpenTelemetry cardinality review should inspect:

1. metric attributes;
2. resource attributes;
3. Collector processors and Views;
4. Datadog mapping configuration;
5. the tags that actually arrive on the metric in Datadog.

Do not infer Datadog cardinality from application instrumentation alone.

Which dimensions are worth keeping?

The most useful test is:

Does this dimension change an operational decision?

A dimension earns its cardinality when teams genuinely use it to make the system easier to operate.

Ask whether it materially changes one or more of these activities.

Alerting

Would different values require different alerts, thresholds or escalation?

SLO analysis

Does the dimension represent a reliability population that must be measured independently?

Incident diagnosis

Does grouping or filtering by the dimension repeatedly narrow the root cause?

Service segmentation

Does it identify a real service, workload or ownership boundary?

Environment isolation

Is it needed to distinguish production, staging or another operational environment?

Capacity analysis

Does the dimension represent an independent scaling or capacity domain?

Deployment analysis

Can it expose a regression affecting one version, deployment, workload, region or cluster?

If the answer is no across all of these, the dimension may still have a legitimate purpose.

But the burden of proof changes.

Cardinality should purchase operational capability.

Dimension-value decision framework

This is not a blacklist.

A bank, retailer, manufacturer or SaaS provider may have valid operational requirements that change some of these decisions.

The important thing is that the exception is intentional and measurable.

How Datadog exposes the cardinality problem

A cardinality review should start with Datadog's own usage evidence rather than with assumptions about which tags look expensive.

Metrics Volume Management

Datadog's Volume Management page surfaces custom-metric volume and identifies high-cardinality metric names, allowing investigation to begin with the metrics that materially contribute to usage rather than reviewing every metric equally.

This matters because metric usage is usually concentrated.

Optimizing one badly dimensioned metric can be more valuable than rewriting instrumentation for hundreds of low-volume metrics.

Metrics Summary and the Tags Cardinality Explorer

Datadog's Metrics Summary includes the Custom Metrics Tags Cardinality Explorer, specifically intended to identify the tag keys responsible for unusually large custom-metric counts or spikes.

This changes the investigation from:

"We probably have too many Kubernetes tags."

to:

"request.route, customer_id and pod_name explain most of the dimensional expansion of these three metric names."

That is the level at which a useful remediation decision can be made.

Metrics without Limits™: ingestion and indexing are not the same thing

Metrics without Limits™ is one of the most important Datadog-specific concepts in a cardinality review.

It allows tags on metrics to be configured so that only an allowlist of tags remains indexed and queryable in Datadog.

This introduces two different volumes:

Ingested Custom Metrics
The original dimensional volume represented by the tags received by Datadog for metrics configured with Metrics without Limits™.

Indexed Custom Metrics
The dimensional volume that remains queryable after the configured tag selection has been applied.

Suppose an application emits:

request.latency
environment:prod
service:payments
cluster:cluster-a
route:/payments/{id}
pod:payments-7dd8d59b5-x4k9p
customer_id:18429

If pod and customer_id are excluded from the indexed tag configuration, that does not mean the application stopped emitting them.

It means Datadog can maintain an indexed representation based on the remaining configured dimensions.

That distinction is fundamental:

Tag configuration changes indexing. Instrumentation changes what is generated and ingested.

The Cardinality Pricing nuance

Under Datadog's current Cardinality Pricing documentation, only metrics configured with Metrics without Limits™ contribute to the Ingested Custom Metrics volume. If a metric is not configured with Metrics without Limits™, Datadog states that the organization is charged only for its indexed custom-metric volume.

Therefore, the statement:

"We removed three tags with Metrics without Limits™, so Datadog no longer ingests those dimensions."

is incorrect.

And the statement:

"Reducing indexed cardinality automatically produces the same financial result under every Datadog contract."

is also incorrect.

The commercial effect depends on the pricing model, current Datadog product rules, usage levels and the organization's executed contract.

Under Metric Name Pricing

For Metric Name Pricing organizations, Datadog exposes ingested and indexed point volume, and tag-management impact is estimated against point volume rather than cardinality volume.

The optimization idea remains useful.

The unit economics are different.

Before and after: reducing cardinality without losing operational value

Consider a hypothetical enterprise running customer-facing services on Kubernetes.

One application emits:

request.latency

with these dimensions:

environment
cluster
service
pod_name
raw_route
http_status
customer_id
request_id

Assume Datadog's cardinality tooling shows that this metric produces approximately 84,000 observed indexed contexts during a representative hour.

This is a hypothetical illustration, not a customer benchmark.

Step 1: establish what each dimension actually provides

The team reviews its monitors, dashboards, SLOs and incident workflow.

It discovers that:

• environment is required to isolate production;
• cluster identifies infrastructure boundaries;
• service identifies ownership;
• route segmentation is heavily used for latency analysis;
• status segmentation is required for error diagnosis;
• pod_name is rarely queried on this application metric;
• customer_id is not used by any monitor or SLO;
• request_id is never aggregated and exists only to locate individual requests;
• raw_route contains resource identifiers.

The problem is no longer "84,000 metrics."

It is now a concrete dimensional model.

Step 2: redesign the metric

The application metric is changed to retain:

environment
cluster
service
normalized_route
status_class

For example:

/orders/918271

becomes:

/orders/{order_id}

request_id remains in traces and logs.

customer_id is removed from this general application metric. If a small, explicitly defined set of customers requires independent SLOs, that requirement can be implemented through a deliberately bounded metric rather than attaching every customer identity everywhere.

pod_name remains available on infrastructure telemetry where pod-level investigation is required, but is removed from the service-level application metric.

Step 3: understand the difference between immediate indexing control and source remediation

An organization might first use Metrics without Limits™ to remove unnecessary tags from the indexed representation.

That can reduce indexed dimensionality quickly.

But if the application continues to emit those tags, the original dimensional telemetry is still being ingested for a metric configured with Metrics without Limits™.

A deeper remediation changes the instrumentation or upstream processing so that unnecessary dimensions are no longer generated for that metric in the first place.

These are two different controls.

What remains possible after the redesign?

The metric can still answer:

• Is production slower than staging?
• Which service regressed?
• Which cluster is affected?
• Which API route is slow?
• Are failures behaving differently from successful requests?
• Did a deployment change the latency distribution?

What it can no longer answer directly is:

"What was the exact latency associated with request ID 98e1...?"

That question belongs naturally to request-level telemetry.

The operational capability has been preserved while event-level identity has been removed from the aggregate metric.

That is what reduce cardinality, not observability means in practice.

No savings percentage should be inferred from this example. Actual financial impact depends on observed usage and the applicable Datadog pricing model.

A practical Datadog cardinality optimization workflow

A serious enterprise review usually follows the problem from usage back to instrumentation rather than starting with a generic list of tags to delete.

1. Find the metric names creating material usage

Use Datadog Metrics Volume Management, Metrics Summary and usage views to identify the metrics that dominate custom-metric volume or have experienced unusual growth.

Do not spend equal effort on every metric.

2. Identify the tag keys driving cardinality

Use the Custom Metrics Tags Cardinality Explorer to identify which dimensions account for the increase.

Look particularly for value populations linked to:

• individual users or customers;
• requests and transactions;
• raw resource identifiers;
• ephemeral workloads;
• Kubernetes metadata;
• newly introduced Prometheus labels;
• OpenTelemetry attributes.

3. Map each dimension back to its source

Determine whether the tag originates from:

• application instrumentation;
• DogStatsD;
• a custom Agent check;
• Kubernetes tag extraction;
• Agent tag-cardinality configuration;
• a Prometheus exporter;
• the OpenMetrics integration;
• OpenTelemetry metric attributes;
• OpenTelemetry resource-to-tag mapping;
• Collector enrichment.

The remediation mechanism depends on the source.

A raw route emitted by application code is not fixed in the same place as a container_id introduced through Datadog Agent tagging.

4. Reconstruct operational dependencies

Before removing a dimension, inspect where it is used.

That includes:

• dashboards;
• monitors;
• SLOs;
• troubleshooting queries;
• notebooks;
• incident runbooks;
• capacity analysis.

A dimension that appears in instrumentation but never participates in an operational workflow deserves scrutiny.

A dimension used by a critical SLO deserves much more caution.

5. Evaluate operational value

For every material dimension, ask:

What decision becomes worse if this dimension disappears?

If there is no convincing answer, investigate whether the dimension should remain.

6. Choose the right control

Different problems require different solutions.

Normalize values when many syntactically unique values represent the same operational category.

/orders/182736
/orders/182737

becomes:

/orders/{order_id}

Aggregate when the metric is more useful at service, workload or region level than at individual-instance level.

Remove the dimension at instrumentation when the information should never have been part of the metric.

Move event identity to logs, traces or exemplars when individual-event investigation is the real requirement.

Adjust Datadog tag cardinality when Agent-generated infrastructure identity is the source.

Use Metrics without Limits™ tag configuration when indexed dimensionality can be reduced while preserving the original ingestion model.

Use OpenTelemetry Views or attribute filtering where cardinality should be controlled before export. OpenTelemetry's SDK specification explicitly applies cardinality limits after attribute filtering, allowing unwanted attributes to be removed before they consume cardinality capacity.

7. Test operational impact

Validate the affected:

• monitors;
• dashboards;
• SLOs;
• alerts;
• capacity queries;
• deployment comparisons;
• troubleshooting workflows.

Do not discover during the next incident that a "useless tag" was the only way operators distinguished two failure populations.

8. Measure the result in Datadog

Verify that the intended metric and dimension changed.

Under Cardinality Pricing, inspect the relevant cardinality volumes.

Under Metric Name Pricing, inspect point-volume effects using the appropriate Datadog views.

Success is not:

"We deleted 40% of the tags."

Success is:

"The unwanted dimensional growth disappeared while the required operational queries still work."

What should not be removed blindly

Several dimensions frequently justify their cost.

Environment

Without production, staging or equivalent segmentation, many operational comparisons become meaningless.

Service

Service identity often defines ownership, alert routing, SLO boundaries and incident diagnosis.

Region and availability zone

These can represent real latency, capacity and failure domains.

Cluster

A distributed platform may need cluster-level segmentation to identify infrastructure-local problems.

Workload or deployment

These dimensions can make deployment regressions and workload-specific failures visible.

Normalized route

Removing route information entirely may make an API metric dramatically cheaper but also incapable of distinguishing one endpoint's behaviour from another.

The pattern is consistent:

Replace unbounded detail with bounded, decision-relevant segmentation. Do not flatten the system into global averages.

Preventing cardinality from returning

Cardinality is an instrumentation property, so it tends to return as systems evolve.

New libraries introduce attributes. Kubernetes labels change. Exporters are upgraded. Teams add dimensions to solve local troubleshooting problems.

The governance required here can remain narrow and technical.

Define a default metric vocabulary

Document the normal dimensions expected on major application metrics.

For example:

environment
service
region
cluster
normalized_route
status_class

Then identify dimensions requiring explicit review:

user_id
customer_id
request_id
session_id
raw_url
container_id

These are examples, not universal policies.

Put ownership on important metrics

Someone should be able to explain:

• why the metric exists;
• which questions it answers;
• why each major dimension exists.

Broader financial attribution by team, service and environment belongs to a separate Observability FinOps cost-attribution model rather than being re-created inside the cardinality policy.

Monitor usage growth

Datadog's own custom-metrics governance guidance recommends visibility into metric usage and its cost drivers rather than discovering unexpected volume only during a commercial review.

Review instrumentation changes close to the source

Where practical, instrumentation standards and CI reviews can flag obvious high-cardinality patterns before deployment.

The cheapest high-cardinality metric to fix is usually the one that has not reached production yet.

When an independent Datadog cardinality review makes sense

An independent review becomes useful when:

• custom-metric usage grows materially faster than traffic or infrastructure;
• engineering cannot explain which dimensions caused the increase;
• a Kubernetes rollout changes metric volume unexpectedly;
• Prometheus/OpenMetrics ingestion introduces a large new custom-metric footprint;
• an OpenTelemetry rollout changes the tag model;
• teams know that cardinality is high but do not know which dimensions can safely be removed;
• Metrics without Limits™ configurations exist but nobody knows whether indexed tags still match operational requirements;
• the financial effect of current metric design needs to be understood before a Datadog commercial decision.

The difficulty is rarely identifying one obviously bad tag.

The work requires correlating:

Datadog usage

with:

metric metadata

with:

instrumentation and integrations

with:

dashboards, monitors and SLOs

with:

the architecture being observed.

Before removing dimensions blindly, determine:

1. which metrics create the custom-metrics footprint;
2. which dimensions drive those metrics;
3. which dimensions actually change operational decisions;
4. whether the right intervention is normalization, aggregation, source removal, Datadog tag configuration or moving detail to another signal;
5. how the resulting usage maps to the organization's actual Datadog pricing model.

SAB Consulting approaches this as an observability architecture and Datadog cost-optimization problem rather than a tag-deletion exercise.

The objective is not the smallest possible metrics footprint.

It is:

the smallest dimensional footprint that still lets engineering operate the system safely.

For broader configuration issues, see Datadog Bill Too High? 12 Configuration Mistakes That Inflate Observability Costs.

For the wider logs, metrics and traces cost model, see Observability Cost Optimization: Where Your Logs, Metrics and Traces Budget Actually Goes.

For ownership and showback, see Observability FinOps: How to Allocate Costs by Team, Service and Environment.

For contract and renewal preparation, see How to Audit Datadog Costs Before Your Next Renewal.

FAQ

What is Datadog metric cardinality?

Datadog defines tag cardinality as the number of values associated with a tag key for a metric. Under Cardinality Pricing, custom-metric usage is based on unique combinations of metric name, host and tags submitted to Datadog, measured hourly and averaged for monthly billing.

Why do tags increase Datadog custom metrics?

A new tag can create additional distinct combinations of metric name and tag values. The effect depends on which combinations actually emit data: the Cartesian product of every possible value is only an upper-bound model, not necessarily the number of observed custom metrics.

Why can Datadog cardinality grow faster than traffic?

Because traffic counts events while cardinality counts dimensional identities. New customers, routes, pods, labels, regions or instrumentation attributes can create additional combinations even when request volume remains unchanged.

Are high-cardinality metrics always expensive in Datadog?

The commercial effect depends on the pricing model. Under Cardinality Pricing, unique custom-metric contexts directly affect the relevant usage count. Under Metric Name Pricing, Datadog instead bills based on metric names and datapoint volume.

Should user IDs or customer IDs be metric tags?

Usually not by default. Prometheus explicitly warns against unbounded label sets such as user IDs. A deliberately bounded customer dimension can still be appropriate when teams genuinely operate per-customer SLOs or other customer-specific reliability controls.

Should request IDs be metric dimensions?

Usually no. Request IDs identify individual events rather than stable aggregation categories. Traces, logs or metric exemplars are generally better mechanisms for preserving request-level identity without putting a unique identifier into every metric series.

How do Kubernetes labels affect Datadog custom metrics?

Datadog can derive tags from Kubernetes labels and annotations, and its Agent also controls which classes of orchestrator and container tags are attached to metrics. Higher-cardinality configurations can increase the number of emitted metric combinations, which Datadog warns can affect billing.

How does Prometheus cardinality affect Datadog?

Every unique Prometheus labelset represents another time series. Metrics collected through Datadog's generic OpenMetrics integration are submitted as custom metrics, so a high-cardinality Prometheus label model can become a high-cardinality Datadog metric model after ingestion.

How does OpenTelemetry affect metric cardinality?

OpenTelemetry metrics use attributes as dimensions. Current OpenTelemetry documentation defines a default cardinality limit of 2,000 unique attribute combinations for a metric stream, after which additional combinations are aggregated into an overflow point. Resource attributes can also become Datadog tags depending on the mapping and ingestion configuration.

What is Metrics without Limits™?

Metrics without Limits™ allows Datadog users to configure which tags remain indexed and queryable on metrics. This separates indexed dimensionality from the original telemetry received for configured metrics. It should not be interpreted as Datadog simply dropping the excluded tag before ingestion.

Can Metrics without Limits™ reduce Datadog custom-metric cost?

It can reduce indexed metric volume, but the financial effect depends on the organization's Datadog pricing model, usage and contract. Under Cardinality Pricing, Datadog separately documents ingested and indexed custom-metric treatment for metrics configured with Metrics without Limits™. Under Metric Name Pricing, the corresponding analysis focuses on ingested and indexed datapoint volume.

How should metric cardinality be reduced without losing observability?

Start with the high-volume metrics, identify which dimensions create their cardinality, map those dimensions back to instrumentation, then determine which ones actually support alerts, SLOs, service segmentation, incident diagnosis, capacity or deployment analysis. Normalize, aggregate, exclude from indexing or move event-level identity to traces and logs only after checking those operational dependencies.

Sources

Datadog

• Datadog — Custom Metrics: custom metric definition and unique metric/tag combinations.
• Datadog — Custom Metrics Billing and Pricing: Cardinality Pricing mechanics and monthly usage model.
• Datadog — Metric Name Pricing for Custom Metrics: metric-name and datapoint-volume billing dimensions.
• Datadog — Metrics Experience Changes for Metric Name Pricing: point-volume representation and tag-change estimates.
• Datadog — Metrics without Limits™: ingested versus indexed custom metrics and tag configuration.
• Datadog — Metrics Summary: Custom Metrics Tags Cardinality Explorer.
• Datadog — Metrics Volume Management: identification of high-cardinality custom metrics.
• Datadog — Assigning Tags / Kubernetes Tag Extraction: low, orchestrator and high cardinality settings and Kubernetes metadata.
• Datadog — OpenMetrics Integration: generic OpenMetrics metrics forwarded as custom metrics.
• Datadog — OpenTelemetry resource and metrics mapping: translation of OpenTelemetry metadata into Datadog tags.
• Datadog — Best Practices for Custom Metrics Governance.

Prometheus / OpenMetrics

• Prometheus — Metric and Label Naming: every unique labelset creates a new time series; unbounded labels such as user IDs should be avoided.
• OpenMetrics specification: metrics are identified by unique labelsets and exemplars can reference traces without becoming primary metric labels.

OpenTelemetry

• OpenTelemetry Metrics SDK: definition and enforcement of metric cardinality limits.
• OpenTelemetry Metrics concepts and glossary: default cardinality limit and overflow behavior.
• OpenTelemetry Attribute Requirement Levels: potentially high-cardinality metric attributes must be Opt-In.