A fleet platform emits 25 metric series per device, tagged with device id, for 400,000 devices. The observability bill is now larger than the compute bill for the platform itself. The team proposes dropping the device id tag and keeping per-model and per-region aggregates. What does that buy, what does it give up, and when does the bill arrive?

What is gained, quantified

25 series x 400,000 devices is 10 million active series. Metrics systems price and scale on series count, because each distinct label combination is a separate time series to index, retain and query. Dropping the device id tag collapses that to 25 series per (model, region) pair: with 12 models and 6 regions, about 1,800 series, a reduction of four orders of magnitude. Query latency improves for exactly the same reason, and the dashboards that leadership looks at — fleet health by model, by region — get faster and cheaper.

What is paid

You lose the ability to ask a question about one device, and that is the question the support desk asks all day: "customer X says their unit is offline, what did it do before it went quiet?" You also lose the class of finding that only appears per device: 800 units in one building all degrading together, a bad batch of a component surfacing as a distribution with two humps, a firmware version behaving differently on one hardware revision.

Aggregates hide exactly the shape you need. A mean across 400,000 devices is a number that no device experiences, and a p99 across the fleet tells you 4,000 devices are unhappy without telling you which — so it generates work rather than answers.

When the cost becomes visible

Not at the change, which is the trap. The dashboards keep working, the bill halves, and the decision looks free for weeks. It becomes visible on the first incident that is not fleet-wide: a regional firmware rollout that harms 2% of units, an integrator who mis-installs 300 devices, a warranty dispute needing per-unit history. At that moment the data you need does not exist retrospectively, and the recovery path is to re-enable the tag and wait.

The design that keeps both

Separate the two jobs rather than trading one for the other:

• Metrics for the fleet, events for the device. Keep low-cardinality aggregate series for alerting and trends, and write per-device records as wide events in columnar storage on object storage, where a device id is a column rather than a series. Cardinality is nearly free in that model, retention is cheaper per byte, and the per-device question is a scan over a time range rather than an index lookup.
• Two retentions. Aggregates for 13 months, per-device events for 14 to 30 days, with a longer window only for units under active investigation.
• Pull on demand. Devices can hold a local ring buffer and upload detail only when asked. This is the cheapest option and it fails exactly when the device is unreachable, which is when you most want the data, so it complements the event stream rather than replacing it.
• Sample by interest, not uniformly. Every device reports a heartbeat and a small vector; devices that are erroring, newly updated, or in a canary cohort report everything.

The decision rule

Choose per-device series only while the device count is small enough that the series count is not the constraint — on the order of thousands, not hundreds of thousands. Above that, per-device detail belongs in an event store and aggregates belong in the metrics system. The rule flips back if your metrics backend genuinely prices on ingested samples rather than series, which a few do; check before you design around it.

When this is the wrong trade

Do not touch the tags if the platform is under 5,000 devices and the bill is a rounding error: you would be trading the diagnostic capability that keeps support costs down for a saving nobody has asked for. The change earns its place when observability spend crosses the cost of the workload it observes, which is the threshold in the question, and it is an unforced error before that point.