Documentationbreadcrumb arrow Grafana Cloudbreadcrumb arrow Platformbreadcrumb arrow Pricing and usagebreadcrumb arrow Metrics
Grafana Cloud

Metrics pricing

Grafana Cloud Metrics bills on the series you send, measured as active series and data points per minute (DPM), and on query volume above a fair use allowance. Understanding how each is measured makes it easier to predict and control what you spend.

For current rates, refer to the pricing page.

Your metrics usage is determined by the number of active series you send and how frequently you send data points for them. Both are measured at the 95th percentile over the billing period.

If your average DPM per active series is greater than the included DPM, your usage is based on total DPM instead of active series. In other words, you’re billed on whichever is higher.

This applies to both hosted Prometheus and hosted Graphite.

Query volume is measured in metrics query units (MQU). Each month, your stack includes a query allowance that scales with the series you send, and only query volume above that allowance is billed. Most customers stay within the allowance. For details, refer to Fair use query allowance.

Definitions

Active series

An active series is a time series that has received new data points within the previous 20 minutes. Shortly after you stop writing new data points to a series, it’s no longer active.

Note

The definition of active series is different for Prometheus native histograms. Refer to Prometheus native histograms.

To view active series data, query the grafanacloud_instance_active_series metric in the grafanacloud-usage data source.

Data points per minute (DPM)

A data point is a single measured occurrence, or sample, of a metric within a time series, consisting of a unique value and timestamp. DPM is the number of data points sent to Grafana Cloud Metrics per minute per series, calculated per stack.

Grafana Cloud measures DPM directly from the data sent to its servers. You can also calculate it by multiplying the number of active series by the number of data points per series per minute.

To calculate data points per series per minute, divide the number of seconds in a minute by your scrape interval:

  • A scrape interval of 15 seconds produces 4 data points per series per minute. This is the Prometheus default.
  • A scrape interval of 60 seconds produces 1 data point per series per minute. This is the default for Grafana Cloud integrations.

To view DPM, query the grafanacloud_instance_samples_per_second metric in the grafanacloud-usage data source, then multiply by 60 to convert to minutes ( * 60).

Included DPM per series

Grafana Cloud Pro accounts include a default resolution of 1 DPM per active series. You can shorten your scrape interval to ship data points more frequently and increase your DPM, for an additional charge. Contracted plans let you choose between the default 1 DPM resolution and a 4 DPM resolution for higher resolution use cases.

To view included DPM per series, query the grafanacloud_org_metrics_included_dpm_per_series metric in the grafanacloud-usage data source.

Metrics query units (MQU)

A metrics query unit (MQU) is the unit Grafana Cloud uses to measure query volume. When you run a query, Grafana Cloud counts the number of samples it reads to produce the result, then converts that number to MQU at a fixed rate of 10 MQU per sample read. The rate is always 10 MQU per sample. What varies between queries is how many samples count as read, as described in the rest of this section. For example, a query that reads 1,000 samples uses 10,000 MQU.

The number of samples read reflects the data your query selects, not how Grafana Cloud processes or executes it. Functions and aggregations applied after the data is read don’t change the number, so foo, sum(foo), and abs(sin(sum(foo))) all read the same number of samples. How Grafana Cloud decides which samples count as read depends on the type of selector.

  • For a range vector selector such as foo[5m], each underlying sample counts as read one time, even when a function such as rate() or avg_over_time() evaluates overlapping windows across many steps. The overlap doesn’t cause the same sample to be counted again.
  • For an instant vector selector such as foo, every sample the selector returns counts as read. In a range query with a step shorter than the scrape interval, the same underlying sample can be returned at more than one step, and each return counts as a sample read.

If a query selects the same data more than once, for example sum(foo) / count(foo), the samples count as read for each selector. Query optimizations such as caching and sharding don’t change the number of samples read.

Instant queries, range queries, and remote read requests all count toward query usage, whether they come from dashboards, Explore, alert and recording rules, or API clients. For how your query usage is compared to your allowance, refer to Query usage calculation.

Fair use query allowance

Each month, your stack includes 20 billion MQU for every 1,000 billable series. Billable series is the same value your active series and DPM usage is rated on. This is the higher of your 95th percentile active series and your total DPM divided by the included DPM. As you send more series, your query allowance grows with them.

Only query volume above the allowance is billed. For the current rate per billion MQU, refer to the pricing page. Contracted plans can include a different allowance. Refer to your contract for the terms that apply to your organization.

Prometheus time series

A Prometheus time series is a list of timestamp and value pairs, or samples, identified by a metric name and zero or more pairs of label names and label values.

For example, consider the following output from a Prometheus metrics exporter:

Bash 
node_cpu_seconds_total{host="host1",cpu="0",mode="user"}
node_cpu_seconds_total{host="host1",cpu="1",mode="user"}

This output contains two time series:

  • The metric name is node_cpu_seconds_total.
  • The label names are host, cpu, and mode.
  • The label values are host1, 0 or 1, and user.

There are two time series because the cpu label value differs, even though host and mode are the same. When you scrape a target and it generates a sample, the sample has a specific timestamp and measured value. Scraping the same target again, for example one minute later, creates a second data point in the same series with a new timestamp and value.

Metrics usage increases quickly when a metric has many different combinations of labels. This is called high cardinality, and it’s best to avoid spikes in cardinality. For example, with 6 CPU modes, 10 hosts, and 4 CPUs, node_cpu_seconds_total counts as 6*10*4, or 240 active series. At a 15 second scrape interval, this produces a DPM per series of 4, or a total DPM of 4*240=960 data points.

For a detailed explanation, refer to the Prometheus data model in the Prometheus documentation.

Graphite time series

For Graphite, unique time series are equivalent to metric paths. For example, the following Graphite output contains eight unique time series:

collect.host1.cpu-0.cpu-idle
collect.host1.cpu-0.cpu-user
collect.host1.cpu-0.cpu-wait
collect.host1.cpu-0.cpu-system
collect.host2.cpu-3.cpu-idle
collect.host2.cpu-3.cpu-user
collect.host2.cpu-3.cpu-wait
collect.host2.cpu-3.cpu-system

If you use Graphite tags, the following output also contains eight unique time series:

Bash 
collect.cpu;host=host1;cpu=0;mode=idle
collect.cpu;host=host1;cpu=0;mode=user
collect.cpu;host=host1;cpu=0;mode=wait
collect.cpu;host=host1;cpu=0;mode=system
collect.cpu;host=host2;cpu=3;mode=idle
collect.cpu;host=host2;cpu=3;mode=user
collect.cpu;host=host2;cpu=3;mode=wait
collect.cpu;host=host2;cpu=3;mode=system

For more information, refer to Graphite tags.

How usage is calculated

The following examples show how usage scales with scrape interval for a Grafana Cloud Pro account:

  • Scenario A: 50,000 active series at a 60-second scrape interval (1 DPM), resulting in 50,000 total DPM:

    Bash 
    usage = max(50000 active_series, 50000 total_dpm / 1 included_dpm) = 50000

  • Scenario B: 50,000 active series at a 30-second scrape interval (2 DPM), resulting in 100,000 total DPM:

    Bash 
    usage = max(50000 active_series, 100000 total_dpm / 1 included_dpm) = 100000

Halving the scrape interval doubles the billable usage for the same number of series.

Usage calculations

The following shows the calculations in pseudo-PromQL.

Active series:

promql 
active_series = quantile_over_time(0.95, sum by (id)(grafanacloud_instance_active_series < Inf)[30d:])

DPM:

promql 
total_dpm = quantile_over_time(0.95, sum by (id)(grafanacloud_instance_samples_per_second < Inf)[30d:]) * 60

Total usage:

promql 
usage = max(active_series, total_dpm/included_dpm)

Query usage calculation

Billable query usage is calculated per stack. The allowance is derived from the stack’s billable series for the billing period, and only MQU above it are billed:

text 
included_mqu = (billable series / 1000) * 20,000,000,000
billable_mqu = max(0, queried_mqu - included_mqu)

For example, a stack rated on 50,000 billable series includes 50 * 20 billion = 1 trillion MQU per month, which is the equivalent of reading 100 billion samples. If the stack’s query usage for the month is 1.2 trillion MQU, 200 billion MQU are billable. For the rate that applies to billable MQU, refer to the pricing page or, for contracted accounts, your contract.

95th percentile billing

For each billing period, Grafana Cloud bills you on the 95th percentile of the active series and total DPM it tracks. This prevents you from being billed for unexpected or temporary spikes, such as when you first configure Prometheus or Grafana Alloy.

Grafana Cloud forgives the top five percent of usage time in each monthly billing period, roughly the top 36 hours in a 720 hour month (0.05 * 720 = 36).

For example, if you normally send around 6,000 active series but spike to 30,000 for a total of 24 hours in a month, you’re still billed at the rate of 6,000 active series.

Note

Usage in the Cost Management and Billing dashboards is a cumulative month-to-date value refreshed hourly, not a per-day total. If you calculate daily usage from it, for example with delta() or increase(), some values can be negative. This is expected, as more data accumulates during the month, the 95th percentile recalculates and the prorated included usage changes, so the month-to-date value can drop. Use the gauge value directly and treat daily differences as approximations.

Special considerations

Prometheus native histograms

Prometheus native histograms are a data type that lets you produce, store, and query high resolution histograms.

Pricing for time series with native histograms depends on the number of buckets used to represent your data distribution. Unlike classic histograms, which use a predefined number of buckets, native histograms provision the number of buckets automatically. The number of active buckets counts toward a billable series at a ratio of 0.25 instead of counting the active series itself. For the same cost, you can use four times as many buckets for native histograms as for classic histograms.

To assess and limit the number of buckets, refer to Analyze the cardinality of native histograms.

OpenTelemetry

Series ingested through the OpenTelemetry Protocol (OTLP) cost no more than any other series. Standard active series pricing applies.

To track OTLP adoption, query the grafanacloud_instance_active_otlp_series metric in the grafanacloud-usage data source.

Volume discounts

As your usage grows, your effective rate decreases automatically. Refer to Volume discounts.

View your usage

  1. In your Grafana Cloud stack, go to Cost Management and Billing > Usage.
  2. Under Product Breakdown, select Metrics.

The Metrics view shows your active series and DPM usage along with your query usage against the fair use allowance. For a deeper breakdown, refer to Understand Metrics usage and cost.