Summary

  • Under Datadog’s documented cardinality model, unconfigured custom metrics are billed for their indexed volume; Metrics without Limits configurations bring both ingested and indexed volumes into the billing calculation, subject to allowances and contract terms.
  • The documented GAUGE example retains four ingested combinations while reducing the index to three. It illustrates separate counting surfaces, not a measured customer saving or a universal rule for every metric type.
  • Metric Name Pricing is a different model, and recent query inactivity is not proof that an asset no longer needs a tag. Pricing scope, queryable dimensions and useful diagnostic work require separate acceptance.

Saving starts with a change in the bill’s perimeter

Datadog’s Custom Metrics Billing page makes its scope explicit: it describes cardinality-based billing, not contracts using Metric Name Pricing SKUs. Within that model, a metric without a Metrics without Limits configuration is billed for indexed custom metrics. Once tags are configured with the feature, both ingested and indexed custom metrics enter the documented billing model.

That is not an allegation of a hidden fee. It is a published distinction between two operating states. A configuration that makes the index smaller can also change the set of volumes the buyer needs to price. Reviewing only the fall in indexed usage would miss the second part of the transaction.

The documentation applies plan allowances and contract-dependent indexed rates. No customer contract, usage account or invoice was examined here. It therefore does not follow that enabling the feature always raises the total bill, or that it always lowers it. The net effect depends on the two volumes, applicable allowances and the prices actually agreed.

The important commissioning question is what the proposed control is supposed to change. If the objective is a lower queryable index with adequate analytical value, this feature can be relevant. If the objective is less telemetry sent from the source, an in-app tag configuration is not evidence that the source volume was reduced.

Four submitted combinations, three queryable combinations

In the billing page’s GAUGE example, the original metric contains four combinations of host, endpoint and status. Keeping only endpoint and status produces three indexed combinations while the ingested volume remains four. These are Datadog’s explanatory numbers, not observations of a customer workload.

The example is useful because it puts both sides of the trade in view. Removing a dimension can collapse combinations that formerly differed by host. The remaining index may answer the intended application question more economically. It will not provide the same host-level distinction through the excluded queryable tag.

A reduced combination count is not a count of source events deleted. Nor does three instead of four imply a matching percentage reduction in the total invoice. The billing perimeter and account allowances have changed what must be compared, and different metric submission types can have different counting behavior.

The buyer should identify the diagnostic distinction being surrendered. A host tag may be irrelevant to a business-level outcome, or essential to an operational question. The answer is workload-specific. Neither “keep everything” nor “drop the highest-cardinality tag” is a sufficient commercial policy.

The Metrics without Limits guide describes both include and exclude configurations for tags that remain queryable across Datadog products. This is a control over queryability. It should not be turned into a claim about deleting the only source copy, stopping ingestion, or guaranteeing historical reconstruction; those were not tested for this article.

A recommendation is not the whole dependency map

The guide’s recommended allowlist draws on tags actively queried over the preceding 30 days. It also says to include tags used on assets even when they have not been actively queried. That second population matters: a quiet dashboard or a dormant operational requirement can still embody a dependency.

The Metrics Summary definitions distinguish “unqueried” from “used.” Unqueried refers to specified forms of access within 30, 60 or 90 days. Used means a metric exists on an asset, regardless of whether it has recently been queried. The two labels answer different questions.

A cleanup programme that equates recent inactivity with dispensability can make a narrow observation do too much work. Lack of recent use may justify a review; it does not establish that the next outage, exception or recurring business cycle will not need the dimension.

Conversely, an asset reference is not a reason to preserve every tag indefinitely. Some references may be obsolete or need redesign. The useful control is a named owner who can explain which questions the retained dimensions must answer and which exceptions are deliberately tolerated.

Datadog allows configuration without requiring agent or code changes. That reduces the friction of editing the index, but not the need to carry the business reason into the change. Ease of adjustment makes review more important when the budget owner and the diagnostic owner are different people.

An estimate, an hour and a month are different evidence

Metrics Summary provides a cardinality preview and says the estimator requires a metric older than 48 hours. This can help screen a proposed tag configuration. It does not make the preview a forecast of the account’s net invoice, particularly when an ingested billing volume is being brought into scope.

The Usage Details page describes custom-metric usage as an average over the hours of the current month. The cardinality billing page likewise averages distinct hourly timeseries. In that model, datapoint submission frequency and query count are not the drivers of billable custom-metric usage.

A peak is not that average. A last-hour estimate is not that average either. Datadog’s hourly-average usage reference distinguishes an average from a maximum and provides month or day resolution. Those definitions help prevent a temporary spike or a current snapshot from being presented as a settled monthly saving.

A fair comparison needs consistent windows, metric types and configuration scope, alongside the contract. It also needs evidence that the intended analytical or operational question remains answerable. Fewer indexed combinations and a useful accepted result can be compatible; neither proves the other.

Another pricing model changes the denominator

The feature guide explicitly separates Metric Name Pricing. Under that model, all submitted datapoints contribute to ingested volume, not only metrics configured with Metrics without Limits. The distribution-metric multiplier also has different stated treatment. The cardinality model’s configured-only ingestion perimeter must not be applied universally.

The metric-volume reference reinforces the distinction: its volume fields are described as estimated hourly timeseries under one interpretation, while for organizations on Metric Name Pricing they represent estimated datapoint sums. A familiar field name is not a guarantee of an unchanged unit.

This is a procurement issue, not merely a dashboard-reading issue. If the contract changes the counting model, a comparison can retain its label while changing its economic meaning. No assumption about a reader’s actual pricing model is made here.

For the cardinality model, Datadog’s configured-only ingested volume is also a billing scope, not a universal statement about whether telemetry reached the platform. An absence from that billable population should not be promoted into proof of absent source submission.

Datadog offers a useful way to buy fewer queryable dimensions without editing the sender. The bargain is defensible when the buyer accepts the pricing perimeter and the diagnostic trade together. A smaller index is an intermediate result. The final result is an adequate set of answers at an understood total cost.

Sources