Which metric label values count as unbounded, and why is 'there are only a few thousand today' the wrong test?

## Bounded and unbounded, precisely A **metric label** is a key/value dimension that forms part of a time series' identity, so the set of values a label can take is the set of series that label will create. A label is **bounded** when that value set is finite, small, and fixed by something you control — an enumeration in code, a short reference list, a set of environment names. It is **unbounded** when the value set is decided by something outside your control: user input, a generated identifier, a clock, a free-text message. "Unbounded" is not a synonym for "large". It means *nothing in the system caps it*. That distinction is the whole question, because the numbers are deceptive in both directions. A bounded label with 400 values is fine. An unbounded label with 30 values today is not. ## The canonical sources | Unsafe label value | Why it is unbounded | Bounded form | |---|---|---| | A member, order or session identifier | One value per entity, growing forever | The entity's *type* or *tier* | | A raw request path | One value per identifier embedded in the URL | The route template | | An error or exception message | Includes timings, ids, remote text | A stable error class or code | | A timestamp, date or duration | Every value is new by construction | A bucketed range, or nothing | | A user agent string | Effectively unlimited variants in the wild | A parsed family name | | A generated instance or build identifier | New value per process or per release | Kept, but counted as churn | Every row has the same shape: something that varies *per event* was made part of an identity that is supposed to vary *per category*. A metric label answers "which kind of thing is this?"; per-event detail belongs on a signal that carries it as an attribute rather than as identity. ## Why "there are only a few thousand today" is the wrong test Three separate reasons, and a strong answer gives at least two: 1. **It measures the symptom, not the mechanism.** The number of distinct values today is an observation about current traffic. Boundedness is a property of where the values come from. If the source is unconstrained, today's count is a sample of a distribution with no ceiling, and it tells you nothing about tomorrow's. 2. **It measures an instant, and the store bills a window.** Values that *rotate* look tiny at any moment and accumulate relentlessly. A label carrying a container or process identifier on a fleet of 47 hosts running 12 containers each shows 564 values at any instant; redeploy eleven times a week and it has created several thousand distinct series across a retention window, none of which disappear when the process does. This is **churn**, and it is invisible to any check that reads the current value count. 3. **It is measured on the wrong traffic.** Counts are usually taken in a low-traffic environment or soon after a rollout, before the long tail of real-world values has appeared. The trap is that the label works. Dashboards render, queries return, nothing warns. The count grows monotonically with traffic and time, and the failure arrives as a step change when the store crosses a memory or index threshold — typically weeks after the change that caused it, and usually attached to the wrong deploy in everyone's mental model. ## The test that actually works Ask **who chooses the value**: - **The code chooses it** — a constant, an enum member, a branch label. Bounded. Its ceiling is visible by reading the source, and it only changes at deploy time. - **A small reference set chooses it** — a list of regions, sites, tiers. Bounded, with a caveat: confirm it is a reference set and not a growing table. A `site` label on nine climbing gyms is fine; a `member` label sourced from the same database is not, and both are "a column in a table". - **Anything else chooses it** — a request, a clock, a remote system, a generated id, an exception's text. Treat it as unbounded, whatever the current count says. Validation does not rescue an unbounded label. A validator that rejects malformed values still admits an unlimited number of well-formed ones; only a validator whose accepted set is an enumeration makes the label bounded. ## What to do with the dimension instead Keeping the dimension usually means changing its *shape* rather than dropping the question. Replace the identifier with the category you would actually group by, replace the concrete path with the route template, replace the message with a class. When the per-event detail genuinely matters, carry it on a signal whose store does not fold it into identity, and keep the metric as the thing that answers "how many, how often, how slow" across categories.