One line of measuring code can turn a single metric into 2,500 billable series, and that count is the part of the bill nobody budgets for. A series is a unique mix of a metric name and its label values. Prometheus writes this rule clearly in its naming guide [1]. A label taking values from your customer data adds to your bill every time traffic brings an unseen value.

The big picture:

The per-host rate reads like a hard cap, but it usually just buys a starting allowance. Vendors bundle a set pool of custom metrics with each watched host, count that pool by the hour across the account, and bill anything extra as pure usage [4]. Grafana Cloud sells the same space as a rate per active series above a flat monthly fee [3].

What strikes me here is how this billing gap changes two different setups. A fleet of small hosts with light measuring stays cheap on a per-host bundle, while a few large hosts tracking customer labels gets costly fast.

Neither vendor hides the math, since both publish the meter and explain the counting rule right next to the listed price. What drifts out of sync is the code. A developer adds a label in a code change to slice a dashboard by tenant name or request number. That standing addition ships to live systems with nobody costing it, and the bill climbs even as the team retires servers.

By the numbers

  • 2,500 series — One metric, three labels: A metric split by method (5 values), status code (10), and endpoint (50) resolves to 5 × 10 × 50 distinct series, which is 250 times the cap Prometheus advises [2].
  • 10 series — The working cap: The project advises keeping a metric’s tally of distinct series below ten, holding the few that pass it to a handful across the whole system [2].
  • $6.50 per 1,000 — The series rate: At this rate, the split metric costs $16.25 a month alone, while the monthly plan fee includes 10,000 active series [3].
  • 100 per host — The bundled pool: The largest tool includes 100 custom metrics per host on its standard plan, counted by the hour across the account at $15 per host per month billed yearly [4].

What I’d watch:

My read is that this is a code review problem wearing a buying disguise, and the reviewers are the developers writing the measuring code.

  • The label source: I’d watch whether a label holds a closed list the code owns, like a region, or an open list the data supplies, like a tenant account. The open kind grows without end, yet it remains unseen on a dashboard.
  • The allowance gap: Hosts times the bundled pool is the only series number the rate card prints. A count above that allowance is priced on a call with sales, so that gap is worth knowing before the renewal hits [4].
  • The meter shape: Many small hosts fit the per-host bundle, while a few large hosts with rich labels fit a per-series rate. Both vendors print enough detail for a team to work out its own answer.
  • The logging trade: Log intake is metered by the gigabyte on the exact same page as the series count [4]. Pushing a wide label into logs moves the bill rather than dropping it, and teams usually make that trade in a hurry [2].
  • The stored data: Prometheus warns that a label with many different values can dramatically raise the amount of data kept, so the same choice shows up on the storage side of the meter too [1].

The catch:

The ten-and-100 guidance is project advice rather than a hard limit. It describes what keeps a time-series store healthy, not what a vendor will charge, and the gap between those two lines is the meter [2][3][4].

My read, held loosely: the math is the part that lasts. A label’s value count is a number a team can work out before a code change merges. That count holds steady even when the rate and the vendor change.

The second limit is day-to-day. Wide detail is often what makes an outage easy to fix, and cutting a label to shrink a bill costs a developer a vital query at three in the morning. The cheaper trade is usually to keep the detail in traces or logs, where the system meters it by volume rather than by mix.

The exact same shift runs through the $2.7 trillion AI (artificial intelligence) bill that turned cost control into a buying requirement, meaning teams must now design their data models directly around the vendor’s meter.

At a glance

  • The Big Shift: Monitor bills are counted in time series, defined as one unique mix of a metric name and its label values, meaning a team pays for how it labels data rather than how many servers it runs.
  • Why It Matters: The per-host rate reads like a cap but acts like an allowance, billing anything extra as usage. The labels that lift a bill are usually added simply to make a dashboard easier to read.
  • What I’d Watch: How the time-series count moves as a system changes shape.
  • Label source: Whether a label holds a closed list the code controls or an open list the customer data supplies.
  • The allowance: The bundled pool per host, times the server count, is the only series number the rate card prints.
  • Meter shape: A per-host bundle compared against a per-series rate, which suit entirely opposite system shapes.
  • The second copy: Wide tracking detail moved into logs is metered by volume instead of by mix.
  • The Catch: The metric caps are project advice rather than measured limits, the pricing models are examples rather than the entire market, and trimming a label costs crucial tracking detail.

Related reading

Sources

[1] Prometheus, “Naming” best practices — https://prometheus.io/docs/practices/naming/ [2] Prometheus, “Instrumentation” best practices — https://prometheus.io/docs/practices/instrumentation/ [3] Grafana Labs, “Grafana Cloud pricing” — https://grafana.com/pricing/ [4] Datadog, “Pricing” — https://www.datadoghq.com/pricing/