# Cost guardrails for custom metrics

Custom metrics are the Datadog line item that surprises teams. The billing counts unique tag-value combinations, so cost control is tag control.

## The guardrails

1. **Usage page review, weekly.** It shows custom metric volume over time. A step change after a deploy names the offending metric. Make this someone job, not nobody job.
2. **Alert on volume.** A monitor on custom metric ingestion volume catches the 10x before the invoice does.
3. **Tag allowlist in code review.** Unbounded values (user IDs, request IDs, IPs, raw URLs) never go on metric tags. They go on log attributes. Enforce with a lint rule on metric emission.
4. **Estimate before shipping.** New metric with tags: multiply out the distinct values per tag. That is the new billable count, roughly. If the number scares you, drop the granular tag.
5. **Metrics without Limits.** Learn ingested vs indexed: you can keep ingesting high-cardinality series for short-term debugging while dropping the indexing (the expensive part) on tags you do not query long-term.
6. **Distributions over histograms** for latency where it fits: server-side percentiles without client-side series sprawl.

## The cleanup runbook

When the bill spikes: Usage page, sort by volume, find the metric, find the tag with runaway cardinality, fix the emitter (remove the tag or bucket the values), and confirm the volume drops. Dashboard edits do not un-bill ingested series; only the emitter fix does.

## Verify

Volume flat for a week after the fix, alert thresholds set just above the new normal, and the tag lint in CI so the next unbounded tag never ships.