DEFAULT_MAX_SERIES_PER_FAMILY

const DEFAULT_MAX_SERIES_PER_FAMILY: 10000 = 10_000

Defined in: src/metrics/MetricsRegistryOptions.ts:25

Built-in cap on distinct label tuples per metric family — the bound that keeps a user-controlled label value from turning one family into a million time series (#131).

Why 10 000 rather than the 1024 the report proposed. A cap only protects if it sits above the largest series count the system can legitimately reach; below that it silently discards real operating data instead of an attack. actor_mailbox_dropped_total carries a path label — one series per dropping actor path — so a node hosting a few thousand sharded entities under back-pressure crosses 1024 with nothing hostile happening at all, and a 1024 cap would fold genuine per-entity drop counts into the overflow series precisely when an operator most needs to read them. 10 000 clears that by an order of magnitude and still bounds the damage: at the ~500 B a series costs in V8, a capped family holds ~5 MB resident instead of the ~500 MB an unbounded million-series family reaches, and the scrape body stays in the hundreds of KB rather than tens of MB. It is also already past the point where a single family is an operational problem worth alerting on, so a deployment that hits the cap wants to hear about it.