# Custom metric rejected or exploding at intake
What you see: the metric never appears in the explorer, or it appears and your custom metric count jumps by thousands overnight.
## Rejected names
Metric names must be lowercase alphanumeric with dots and underscores (no spaces, no dashes, no uppercase). Invalid names are dropped at intake; over UDP (DogStatsD) there is no client-side error, the packets just vanish. If a new metric never shows up, check the name first.
## Cardinality explosion
The billing docs are explicit: the count is per unique tag-value combination, scaling with the most granular tag. So:
- `http.requests` tagged `status` (5 values): 5 metrics. Fine.
- `http.requests` tagged `user_id` (200k values): 200k metrics. Invoice.
Tags like request_id, session_id, container_id, and raw URLs have the same effect. The value belongs in a log attribute or a trace tag, not on a metric.
## Fix
1. Rename to valid characters.
2. Drop unbounded tags at emission. If you need the breakdown, keep a low-cardinality bucket (status code class, endpoint pattern) on the metric and the full value on the log line.
3. Check the Usage page for the offending metric name, then fix the emitter. Dashboard edits do not un-bill ingested series.
## Prevention
Lint metric names and tag keys in CI. A one-line check (lowercase, allowed chars, tag key allowlist) saves the surprise bill and the cleanup.