Grafana Cloud Pricing (2026): How One Label Turns a $0 Bill Into $2,089

Quick Answer (2026): Grafana Cloud's Free tier covers 10,000 active metric series, 50 GB of logs, and 50 GB of traces at no cost, with 14-day retention and 3 users. The Pro plan adds a 19 dollar per month platform fee and then meters metrics at 6.50 dollars per 1,000 active series above the 10,000 allotment (Grafana Cloud pricing, 2026). Here is the part nobody warns you about: the bill almost never dies on how much traffic you get. It dies on cardinality. One label with an unbounded value, a user ID, a raw URL, an email address, can multiply your series count by 30 times or more overnight. This teardown walks three real 30-day bills and the single lever that pulls a 2,089 dollar month back to zero.

The meter that actually charges you

Grafana Cloud does not bill the paid metrics line by requests, dashboards, or users. It bills by active series. An active series is one unique combination of a metric name and its label values that received at least one sample in the billing period. Two labels, method="GET" and method="POST", on the same metric are two separate series.

That matters because series count is multiplicative, not additive. A metric with labels method (4 values), status (5 values), and route (10 values) is not 19 series. It is 4 x 5 x 10 = 200 series. Add one more label with 100 values and it becomes 20,000. The Prometheus docs, which describe the exact data model Grafana Cloud bills against, put it plainly: "Each labelset is an additional time series that has RAM, CPU, disk, and network costs" (Prometheus instrumentation practices, 2026). Grafana Cloud simply attaches a price to that sentence.

The 2026 price ladder

Source of truth: the Grafana Cloud pricing page, read July 2026.

Keep the two headline numbers in your head: 10,000 free series, then 6.50 dollars per 1,000. Every bill below is just arithmetic on those two.

Bill #1: the disciplined service (0 dollars per month)

Start with a service that labels things properly. One request-duration histogram with 8 buckets emits 10 series per label combination (8 buckets plus _sum plus _count). Give it method (4), status (5), and route (10 templated routes like /orders/:id, never the raw path):

• 4 x 5 x 10 = 200 label combinations
• 200 x 10 series each = 2,000 active series from that one histogram

Stack a dozen more counters and gauges with sane labels and a typical small production service lands around 8,500 active series. Logs run 24 GB per month, traces 12 GB. Every one of those sits under the free caps (10,000 series, 50 GB, 50 GB).

30-day bill: 0.00 dollars. Most small apps genuinely never need to pay Grafana Cloud a cent. Which is exactly why the next bill catches people off guard.

Bill #2: one label, 2,089 dollars

Same service. A well-meaning engineer wants to see per-user request counts, so they add a user_id label to one request counter across 8 endpoints. The app has 40,000 monthly active users.

That single counter now generates:

• 8 endpoints x 40,000 unique user IDs = 320,000 active series

The other 8,500 series have not moved. But the total is now 328,500 active series, a 38x jump caused by one label on one metric. Run the meter:

• Billable series: 328,500 minus the 10,000 allotment = 318,500
• 318,500 / 1,000 x 6.50 dollars = 2,070.25 dollars
• Plus the 19 dollar platform fee

30-day bill: 2,089.25 dollars. From a single word in a label.

Here is the whole ladder so you can find your own number:

The one-lever fix

The fix is not a Grafana setting. It is a rule about where identifiers live.

High-cardinality identifiers, user IDs, request IDs, emails, raw paths, order numbers, belong in logs and traces, never in metric labels. The Prometheus maintainers recommend keeping a metric's cardinality under 10 and warn that anything with the potential to grow past 100 should move "away from monitoring and to a general-purpose processing system" (Prometheus instrumentation practices, 2026). A per-user counter fails that test by four orders of magnitude.

Delete the user_id label. Series fall from 328,500 back to 8,500, under the 10,000 free allotment. If you want the 13-month retention you stay on Pro and pay the 19 dollar fee; if you do not, you drop to Free.

• Before: 2,089.25 dollars per month
• After: 19 dollars (Pro) or 0 dollars (Free)

One label. 2,070 dollars per month. That is the single highest-leverage line in your entire observability budget.

Bill #3: the second meter (logs)

Metrics is not the only thing with a silent multiplier. Logs bill on ingested volume, and the fastest way to blow it up is leaving DEBUG logging on in production.

A mid-size service shipping verbose logs hits 900 GB per month. On Pro, 50 GB is included, so 850 GB is billable:

• Write: 850 x 0.40 dollars = 340 dollars
• Retain: 850 x 0.10 dollars = 85 dollars
• Process (query-driven, varies): extra on top
• Platform fee: 19 dollars

30-day floor: about 444 dollars, before query processing.

Lever: set the production log level from DEBUG to WARN, or sample debug lines. A 70 percent volume cut takes you to 270 GB, so 220 GB billable:

• Write: 220 x 0.40 dollars = 88 dollars
• Retain: 220 x 0.10 dollars = 22 dollars
• Plus 19 dollars = 129 dollars

Saved: about 315 dollars per month for a one-line config change.

When self-hosting starts to win

The usual build-vs-buy question. Grafana Cloud's metrics line crosses a 40 dollar per month small-VPS budget at roughly 16,150 active series (about 6,150 billable series on top of the 10,000 allotment). Above that, a self-hosted Prometheus or Mimir stack on your own box is cheaper on the invoice.

But the invoice is not the whole cost. Self-hosting means you now own the upgrades, the storage growth, the alerting reliability, and the 3am page when the metrics box itself falls over. The rule we keep coming back to: hosted wins until the metered line clearly beats a fixed box plus the hours to run it. We ran the full version of that trade in when DIY beats SaaS at scale.

Grafana Cloud vs Datadog: same trap, different meter

If you are pricing alternatives, know that switching vendors does not switch off the cardinality trap. Datadog meters observability differently, per-host infrastructure pricing plus a custom-metrics line, but custom metrics are still counted by the same unique-label-combination logic, and a runaway user_id label costs money there too (check current rates on the Datadog pricing page, 2026). The meter shape changes; the discipline does not. Whoever you buy from, the winning move is keeping unbounded identifiers out of metric labels.

The 60-second cardinality audit

Before your next invoice:

1. Grep your metric definitions for label names like id, user, email, path, uuid, session. Each one is a suspect.
2. Query your top series by cardinality (Prometheus /api/v1/status/tsdb exposes the worst offenders).
3. Set a per-tenant active-series limit so a bad deploy fails loud instead of billing quiet.
4. Move every unbounded identifier from a metric label into a log field or a trace attribute.

Do that once and Bill #2 can never happen to you.

Math check: 6.50 dollars per 1,000 series times 318,500 billable series is 2,070.25 dollars, so a single 320,000-series label is 99 percent of a 2,089 dollar bill. Cardinality, not traffic, is the meter that bites.