Google Cloud Observability pricing examples

This page provides pricing examples for Google Cloud Observability. You can use the examples on this page to help you understand how Google Cloud computes your Google Cloud Observability costs. For pricing information, see Google Cloud Observability pricing.

You might also be interested in the following documents:

• Estimate your bills. This document describes how to view your usage and estimate your bills.

• Optimize and monitor your costs. This document helps you reduce or monitor your costs.

• Optimize costs with the Cost Explorer. The Cost Explorer provides current and historical visualizations of cost data and utilization metrics. As such, the data helps you identify optimization opportunities.

Alerting policies

This section describes how to compute the number of monitored time series and provides several pricing examples.

Count the number of monitored time series

Consider a configuration where you have the following:

• 100 virtual machines (VMs), where each VM belongs to one service.
• Each VM emits one metric, metric_name, which has a label with 10 values.
• Five total services.

Since you have 100 VMs, which each can generate 10 time series (one for each label value), you have a total of 1,000 underlying time series. Each VM also contains a metadata-like label that records which of your five services the VM belongs to.

You could configure your alerting policies in the following ways by using PromQL, where each configuration results in a different number of time series returned per execution period:

Pricing examples

The following examples take place in a 30-day month, resulting in the following evaluation periods:

• 86,400 30-second execution periods per month
• 172,800 15-second execution periods per month (PromQL queries only)

Example 1: One policy, aggregating to the VM, 30 seconds

In this example, use the following configurations:

Data

• 100 VMs
• Each VM emits one metric, metric_name
• metric_name has one label, which has 10 values

• One alert condition
• Condition aggregates to the VM level
• 30-second execution period

• Condition cost: 1 condition * $0.10 per month = $0.10 per month
• Time series cost: 100 time series returned per period * 86,400 periods per month = 8.6 million time series returned per month * $0.35 per million time series = $3.02 per month
• Total cost: $3.12 per month

Example 2: 100 policies (one per VM), aggregating to the VM, 30 seconds

In this example, use the following configurations:

Data

• 100 VMs
• Each VM emits one metric, metric_name
• metric_name has one label, which has 10 values

• 100 conditions
• Each condition is filtered and aggregated to one VM
• 30-second execution period

• Condition cost: 100 conditions * $0.10 per month = $10 per month
• Time series cost: 100 conditions * 1 time series returned per condition per period * 86,400 periods per month = 8.6 million time series returned per month * $0.35 per million time series = $3.02 per month
• Total cost: $13.02 per month

Example 3: One policy, aggregating to the VM, 15 seconds

In this example, use the following configurations:

Data

• 100 VMs
• Each VM emits one metric, metric_name
• metric_name has one label, which has 10 values

• One PromQL alert condition
• Condition aggregates to the VM level
• 15-second execution period

• Condition cost: 1 condition * $0.10 per month = $0.10 per month
• Time series cost: 100 time series returned per period * 172,800 periods per month = 17.3 million time series returned per month * $0.35 per million time series = $6.05 per month
• Total cost: $6.15 per month

Example 4: Aggregate one policy to each service, 30 seconds

In this example, use the following configurations:

Data

• 100 VMs, where each VM belongs to one service
• Five total services
• Each VM emits one metric, metric_name
• metric_name has one label, which has 10 values

• One condition
• Condition aggregates to the service level
• 30-second execution period

• Condition cost: 1 condition * $0.10 per month = $0.10 per month
• Time series cost: 5 time series returned per period * 86,400 periods per month = 432,000 time series returned per month * $0.35 per million time series = $0.14 per month
• Total cost: $0.24 per month

Example 5: Aggregate one policy to the VM; higher underlying cardinality per VM, 30 seconds

In this example, use the following configurations:

Data

• 100 VMs
• Each VM emits one metric, metric_name
• metric_name has 100 labels with 1,000 values each

• One condition
• Condition aggregates to the VM level
• 30-second execution period

• Condition cost: 1 condition * $0.10 per month = $0.10 per month
• Time series cost: 100 time series returned per period * 86,400 periods per month = 8.5 million time series returned per month * $0.35 per million time series = $3.02 per month
• Total cost: $3.12 per month

Example 6: Aggregate one policy to the VM; union two metrics in one condition, 30 seconds

In this example, use the following configurations:

Data

• 100 VMs
• Each VM emits two metrics, metric_name_1 and metric_name_2
• Both metrics have one label with 10 values each

• One condition
• Condition aggregates to the VM level
• Condition uses an OR operator to union the metrics
• 30-second execution period

• Condition cost: 1 condition * $0.10 per month = $0.10 per month
• Time series cost: 2 metrics * 100 time series returned per metric per period * 86400 periods per month = 17.3 million time series returned per month * $0.35 per million time series = $6.05 per month
• Total cost: $6.15 per month

Example 7: 100 log-based alerting policies

In this example, use the following configuration:

Alerting policies

• 100 conditions (one condition per log-based alerting policy)

• Condition cost: 100 condition * $0.10 per month = $10.00 per month
• Time series cost: $0 (Log-based alerting policies do not return time series.)
• Total cost: $10.00 per month

Cloud Monitoring API pricing example

This example is of pricing as of October 2, 2025.

Suppose you query 10 metric types every 5 minutes and that for each metric type, the number of returned time series is 100. In 30 days, your queries return 8,640,000 time series (10 metric types * 100 time series / metric type * (60 minutes / hour / 5 minutes polling interval) * 24 hours / day * 30 days).

The cost per 30 days is $3.82 ((8,640,000 - 1 million time series free allotment) * ($0.50/million time series returned)).

Metric data charged by bytes ingested

The following examples illustrate how to get an estimate of costs for collecting metric data for metrics charged by bytes ingested. These examples are intended to illustrate calculations; for comprehensive estimates, use the Pricing Calculator. If you access this tool, use Google Cloud Observability product to enter you metric, logging, and trace data.

The basic scenario is this: You have some number of monitored resources, such as Compute Engine, Google Kubernetes Engine, or App Engine, that are writing data from some number of metrics each month.

The variables across the scenarios include:

• The number of resources.
• The number of metrics.
• Whether the metrics are Google Cloud metrics or not.
• The rate at which the metric data is written.

The examples in this section are for Monitoring pricing as of July 2020.

Common background

In the following pricing examples, each metric data point ingested is assumed to be of type double, int64, or bool; these count as 8 bytes for pricing purposes. There are roughly 730 hours (365 days / 12 months * 24 hours) in a month, or 43,800 minutes.

For one metric writing data at the rate of 1 data point/minute for one month:

• Total data points is: 43,800
• Total volume ingested is:
  • 350,400 bytes (43,800 data points * 8 bytes)
  • 0.33416748 MiB (350,400 bytes / 1,048,576 bytes/MiB)

For one metric writing data at the rate of 1 data point/hour for one month:

• Total data points is: 730
• Total volume ingested:
  • 5,840 bytes (730 data points * 8 bytes)
  • 0.005569458 MiB (5,840 bytes / 1,048,576 bytes/MiB)

Pricing examples

Scenario 1: You have 1,000 resources, each writing 75 metrics. These are Google Cloud metrics only, writing at the rate of 1 data point/minute.

• Monthly ingestion: 25,063 MiB: 0.33416748 MiB for one metric * 75,000 (that is, 1,000 resources, 75 metrics)
• Approximate cost per month: $0.00 (Google Cloud metrics are included free)

Scenario 2: You have 1,000 resources, each writing 75 custom metrics. These are chargeable metrics writing at the rate of 1 data point/minute.

• Monthly ingestion: 25,063 MiB (same as above)
• Approximate cost per month: $6,427.55

Scenario 3: You have 1,000 resources, each writing 75 custom metrics. These are chargeable metrics writing at the rate of 1 data point/hour.

• Monthly ingestion: 418 MiB = 0.005569458 MiB for one metric * 75,000
• Approximate cost per month: $69.14

Scenario 4: You have 1 resource writing 500,000 metrics. These are chargeable metrics writing each at the rate of 1 data point/minute.

• Monthly ingestion: 167,084 MiB: 0.33416748 MiB for one metric * 500,000
• Approximate cost per month: $35,890.98

Metric data charged by samples ingested

The following examples illustrate how to estimate the costs for collecting metrics charged by samples ingested. Sample-based charging is used for Google Cloud Managed Service for Prometheus.

These examples are intended to illustrate calculation techniques, not to provide billing data.

The basic scenario is this: You have some number of containers or pods that are writing points across some number of time series each month. The data might consist of scalar values or distributions.

The variables across the scenarios include:

• The number of containers or pods.
• The number of time series.
• Whether the data consists of scalar values, distributions, or both.
• The rate at which the data is written.

Counting samples

Before you can estimate prices, you need to know how to count samples. The number of samples counted for a value depends on the following:

• Whether the value is a scalar or a distribution
• The rate at which the values are written

This section describes how to estimate the number of samples written for a time series over the monthly billing period.

In a month, there are roughly 730 hours (365 days / 12 months * 24 hours), 43,800 minutes, or 2,628,000 seconds.

If a time series writes scalar values, then each value counts as one sample. The number of samples written in a month depends only on how frequently the values are written. Consider the following examples:

• For values written every 15 seconds:
  • Write rate: 1 value/15s = 1 sample/15s
  • Samples per month: 175,200 (1 sample/15s * 2,628,000 seconds/month)
• For values written every 60 seconds:
  • Write rate: 1 value/60s = 1 sample/60s
  • Samples per month: 43,800 (1 sample/60s * 2,628,000 seconds/month)

If a time series writes distribution values, then each value can contain 2 + n samples, where n is the number of buckets in the histogram. The number of samples written in a month depends on the number of buckets in your histograms and on how frequently the values are written.

For example, each instance of a 50-bucket histogram can contain 52 samples. If the values are written once every 60 seconds, then a 50-bucket histogram writes at most 2,277,600 samples per month. If the histogram has 100 buckets and is written once every 60 seconds, then each histogram can contain 102 samples and writes at most 4,467,600 samples per month.

Most distribution time series contain fewer than the maximum number of samples. In practice, between 20% and 40% of histogram buckets are empty. This percentage is even higher for users with sparse histograms, such as those generated by Istio.

When counting samples for pricing, only buckets with non-empty values are included. The maximum number of samples per histogram is 2 + n . If 25% of your buckets are empty, then the expected number of samples is 2 + .75n per histogram. If 40% of your buckets are empty, then the expected number of samples is 2 + .60n per histogram.

The following calculations and summary table show the maximum number of samples and more realistic expected numbers of samples:

• For 50-bucket histogram values written every 15 seconds:

  • Write rate: 1 value/15s
  • Maximum samples:
    • Per histogram: 52
    • Per month: 9,110,400 (52 * 1 value/15s * 2,628,000 seconds/month)
  • Expected samples, assuming 25% empty:
    • Per histogram: 39.5 (2 + .75(50), or 2 + (50 - 12.5))
    • Per month: 6,920,400 (39.5 * 1 value/15s * 2,628,000 seconds/month)
  • Expected samples, assuming 40% empty:
    • Per histogram: 32 (2 + .6(50), or 2 + (50 - 20))
    • Per month: 5,606,400 (32 * 1 value/15s * 2,628,000 seconds/month)

• For 50-bucket histogram values written every 60 seconds:

  • Write rate: 1 value/60s
  • Maximum samples:
    • Per histogram: 52
    • Per month: 2,277,600 (52 * 1 value/60s * 2,628,000 seconds/month)
  • Expected samples, assuming 25% empty:
    • Per histogram: 39.5 (2 + .75(50), or 2 + (50 - 12.5))
    • Per month: 1,730,100 (39.5 * 1 value/60s * 2,628,000 seconds/month)
  • Expected samples, assuming 40% empty:
    • Per histogram: 32 (2 + .6(50), or 2 + (50 - 20))
    • Per month: 1,401,600 (32 * 1 value/60s * 2,628,000 seconds/month)

• For 100-bucket histogram values written every 15 seconds:

  • Write rate: 1 value/15s
  • Maximum samples:
    • Per histogram: 102
    • Per month: 17,870,400 (102 * 1 value/15s * 2,628,000 seconds/month)
  • Expected samples, assuming 25% empty:
    • Per histogram: 77 (2 + .75(100), or 2 + (100 - 25))
    • Per month: 13,490,400 (77 * 1 value/15s * 2,628,000 seconds/month)
  • Expected samples, assuming 40% empty:
    • Per histogram: 62 (2 + .6(100), or 2 + (100 - 40))
    • Per month: 10,862,400 (62 * 1 value/15s * 2,628,000 seconds/month)

• For 100-bucket histogram values written every 60 seconds:

  • Write rate: 1 value/60s
  • Maximum samples:
    • Per histogram: 102
    • Per month: 4,467,600 (102 * 1 value/60s * 2,628,000 seconds/month)
  • Expected samples, assuming 25% empty:
    • Per histogram: 77 (2 + .75(100), or 2 + (100 - 25))
    • Per month: 3,372,600 (77 * 1 value/60s * 2,628,000 seconds/month)
  • Expected samples, assuming 40% empty:
    • Per histogram: 62 (2 + .6(100), or 2 + (100 - 40))
    • Per month: 2,715,600 (62 * 1 value/60s * 2,628,000 seconds/month)

The following table summarizes the preceding information:

Pricing examples

To estimate prices, count the number of samples written over a month and apply the pricing values. Samples are priced by the million, for stacked ranges, as follows:

The rest of this section works through possible scenarios.

Scenario 1: You have 100 containers, each writing 1,000 scalar times series.

Variant A: If each time series is written every 15 seconds (1 sample/15s), then the number of samples written per month is 17,520,000,000 (175,200 samples/month * 1,000 time series * 100 containers), or 17,520 million.

Variant B: If each time series is written every 60 seconds (1 sample/60s), then the number of samples written per month is 4,380,000,000 (43,800 samples/month * 1,000 time series * 100 containers), or 4,380 million.

In both of these cases, there are fewer than 50,000 million samples, so only the first rate applies. No samples are charged at the other rates.

Scenario 2: You have 1,000 containers, each writing 1,000 scalar times series.

Variant A: If each time series is written every 15 seconds (1 sample/15s), then the number of samples written per month is 175,200,000,000, or 175,200 million:

• The first 50,000 million samples are charged at the first rate.
• The remaining 125,200 million samples are charged at the second rate.
• There are no samples charged at the other rates.

Variant B: If each time series is written every 60 seconds (1 sample/60s), then the number of samples written per month is 43,800,000,000, or 43,800 million. This monthly value is less than 50,000 million samples, so only the first rate applies.

Scenario 3: You have 100 containers, each writing 1,000 100-bucket distribution times series. You expect 25% of the buckets to be empty.

Variant A: If each time series is written every 15 seconds (1 sample/15s), then the number of samples written per month is 1,349,040,000,000 (13,490,400 samples/month * 1,000 time series * 100 containers), or 1,349,040 million.

• The first 50,000 million samples are charged at the first rate.
• The next 200,000 million samples are charged at the second rate.
• The next 250,000 million samples are charged at the third rate.
• The remaining 749,040 million samples are charged at the fourth rate.

Variant B: If each time series is written every 60 seconds (1 sample/60s), then the number of samples written per month is 337,260,000,000 (3,372,600 samples/month * 1,000 time series * 100 containers), or 337,260 million.

• The first 50,000 million samples are charged at the first rate.
• The next 200,000 million samples are charged at the second rate.
• The remaining 87,260 million samples are charged at the third rate.

Scenario 4: You have 1,000 containers, each writing 10,000 100-bucket distribution times series. You expect 40% of the buckets to be empty.

Variant A: If each time series is written every 15 seconds (1 sample/15s), then the number of samples written per month is 108,624,000,000,000 (10,862,400 samples/month * 10,000 time series * 1,000 containers), or 108,624,000 million.

• The first 50,000 million samples are charged at the first rate.
• The next 200,000 million samples are charged at the second rate.
• The next 250,000 million samples are charged at the third rate.
• The remaining 108,124,000 million samples are charged at the fourth rate.

Variant B: If each time series is written every 60 seconds (1 sample/60s), then the number of samples written per month is 27,156,000,000,000 (2,715,600 samples/month * 10,000 time series * 1,000 containers), or 27,156,000 million.

• The first 50,000 million samples are charged at the first rate.
• The next 200,000 million samples are charged at the second rate.
• The next 250,000 million samples are charged at the third rate.
• The remaining 26,656,000 million samples are charged at the fourth rate.

Scenario 5: You have the following:

• 1,000 containers, each writing 1,000 scalar times series every 15 seconds. The number of samples written per month is 175,200,000,000, or 175,200 million. (Scenario 2, variant A.)

• 1,000 containers, each writing 10,000 100-bucket distribution times series every 15 seconds. You expect 40% of the buckets to be empty. The number of samples written per month is 108,624,000,000,000 or 108,624,000 million. (Scenario 4, variant A.)

The total number of samples per month is 108,799,200 million (175,200 million + 108,624,000 million).

• The first 50,000 million samples are charged at the first rate.
• The next 200,000 million samples are charged at the second rate.
• The next 250,000 million samples are charged at the third rate.
• The remaining 108,299,200 million samples are charged at the fourth rate.

Uptime-check execution

This example is of pricing as of (Effective date: October 1, 2022).

The following examples illustrate how to estimate the costs for executing uptime checks. These examples are intended to illustrate calculation techniques, not to provide billing data.

Counting executions of uptime checks

To estimate the cost of your uptime checks, you need to know how many regional executions occur in a month. Monitoring charges $0.30/1,000 executions, with a free monthly allotment of 1 million executions.

To estimate the cost of your uptime checks, you can use the following calculation:

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

For each uptime check, the number of executions depends on the following configuration choices:

• How frequently the uptime check executes: every minute, 5 minutes, 10 minutes, or 15 minutes.

• The number of regions in which the uptime check executes.

• The number of targets the uptime check is configured for. If the uptime check is configured for a single VM, then the number of targets is 1. If the uptime check is configured for a resource group, then the number of targets is the number of resources in the group.

When you configure an uptime check, you specify a location for the uptime check, and each location maps to one or more regions. The following table shows the valid locations for uptime checks and the regions to which they map:

You must configure your uptime checks to execute in at least three regions.

To estimate the number of executions for an uptime check, you need to know how many regions are covered by the uptime-check location:

• ASIA_PACIFIC, EUROPE, and SOUTH_AMERICA each include 1 region.
• USA includes 3 regions.
• GLOBAL includes 6 regions.

In a month, there are roughly 730 hours (365 days / 12 months * 24 hours) or 43,800 minutes.

• An uptime check configured to run once a minute in USA runs in a 3 regions. If this uptime check is configured to check a single VM, then this uptime check executes 131,400 (3 * 43,800) times in a month. If the check is configured to check a 10-member resource group, then the uptime check executes 1,314,000 (10 * 131,400) times in a month.

• An uptime check configured to run once a minute in ASIA_PACIFIC, EUROPE, and USA runs in 5 regions. This uptime check executes 219,000 times in a month if configured for a single target.

The following table shows the hourly and monthly execution counts for a single uptime check configured to run with different frequencies in different numbers of regions:

Pricing examples

To estimate prices, determine your total monthly executions and subtract 1,000,000. Any remaining executions are charged at $0.30/1,000 executions, so multiply the remaining executions by .0003.

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

Scenario 1: You have 1 uptime check in location USA that checks 1 VM once a minute. This check runs in 3 regions. The check executes 131,400 times a month and costs nothing.

Scenario 2: You have 1 uptime check in location USA that checks a 10-member resource group once a minute. This check runs in 3 regions. The check executes 10 * 131,400 times a month and costs $94.20/month. The only difference between this scenario and Scenario 1 is the number of targets.

Scenario 3: You have 10 GLOBAL uptime checks, each of which checks 1 VM once a minute. These checks run in 6 regions, so each check executes 262,800 times a month. The total monthly executions is 2,628,000 (10 * 262,800). This scenario costs $488.40/month.

Scenario 4: You have 5 uptime checks in location USA that check 1 VM once every 5 minutes. These checks run in 3 regions, so each check executes 26,280 times a month. The total monthly executions for this set of checks is 105,120 (4 * 26,280).

You also have 2 GLOBAL uptime checks that check 1 VM once every 15 minutes. These checks run in 6 regions, so each check executes 17,520 times a month. The total monthly executions for this set of checks is 35,040 (2 * 17,520).

Your total monthly executions is 140,160 (105,120 + 35,040). This scenario costs nothing.

Synthetic-monitor execution pricing example

(Effective date: November 1, 2023).

Assume that you create 3 synthetic monitors and configure each of them to execute every 5 minutes, then your total number of executions per month is 26,784:

Number of executions per month =  3 synthetic monitors * 1 execution per monitor per 5 minutes *
                                  1440 minutes per day * 31 days per month
                               =  26,784

To determine the number of chargeable executions, subtract the free allotment from the total number of executions, and then multiple the result by the cost:

Cloud Trace pricing examples

The example is for Trace pricing as of July 2020.

• If you ingest 2 million spans in a month, your cost is $0. (Your first 2.5 million spans ingested in a month are free.)
• If you ingest 14 million spans in a month, your cost is $2.30. (Your first 2.5 million spans in a month are free. The remaining spans' cost is calculated as 11.5 million spans * $0.20/million spans = $2.30.)
• If you ingest 1 billion spans in a month, your cost is $199. (Your first 2.5 million spans in a month are free. The remaining spans' cost is calculated as 997.5 million spans * $0.20/million spans = $199.50.)