Cloud Monitoring quotas and limits

This document lists the quotas and system limits that apply to Cloud Monitoring. Quotas specify the amount of a countable, shared resource that you can use, and they are defined by Google Cloud services such as Cloud Monitoring. System limits are fixed values that cannot be changed.

Google Cloud uses quotas to help ensure fairness and reduce spikes in resource use and availability. A quota restricts how much of a Google Cloud resource your Google Cloud project can use. Quotas apply to a range of resource types, including hardware, software, and network components. For example, quotas can restrict the number of API calls to a service, the number of load balancers used concurrently by your project, or the number of projects that you can create. Quotas protect the community of Google Cloud users by preventing the overloading of services. Quotas also help you to manage your own Google Cloud resources.

The Cloud Quotas system does the following:

  • Monitors your consumption of Google Cloud products and services
  • Restricts your consumption of those resources
  • Provides a way to request changes to the quota value

In most cases, when you attempt to consume more of a resource than its quota allows, the system blocks access to the resource, and the task that you're trying to perform fails.

Quotas generally apply at the Google Cloud project level. Your use of a resource in one project doesn't affect your available quota in another project. Within a Google Cloud project, quotas are shared across all applications and IP addresses.

To adjust most quotas, use the Google Cloud console. For more information, see Request a quota adjustment.

There are also system limits on Monitoring resources. System limits can't be changed.

User-defined metrics

The Cloud Monitoring Metrics Management page provides information that can help you control the amount you spend on billable metrics without affecting observability. The Metrics Management page reports the following information:

  • Ingestion volumes for both byte- and sample-based billing, across metric domains and for individual metrics.
  • Data about labels and cardinality of metrics.
  • Number of reads for each metric.
  • Use of metrics in alerting policies and custom dashboards.
  • Rate of metric-write errors.

You can also use the Metrics Management to exclude unneeded metrics, eliminating the cost of ingesting them. For more information about the Metrics Management page, see View and manage metric usage.

Category Maximum value
Custom metric descriptors per project1 10,000
Labels per metric descriptor 30
String length for label key 100
String length for label value 1024
Time series included in a write request2 200
Rate at which data can be written to a single time series3 one point each 5 seconds
Histogram buckets per custom distribution metric 200
Workload, Prometheus, and external4 metric descriptors per project 25,000
Active time series from custom metrics per monitored resource5 200,000
Active time series from workload metrics per monitored resource5 200,000
Active time series from Prometheus per monitored resource5 1,000,000
Active time series from external metrics per monitored resource5 200,000
Rate at which metric descriptors can be created 6,000 per minute per project

1 This limit is imposed by Cloud Monitoring. Other services might impose lower maximum values. Custom metrics are those written to custom.googleapis.com.
2 You can write only one data point for each time series in a request, so this limit also functions as the maximum number of points that can be written per request.
3 The Cloud Monitoring API requires that the end times of points written to a time series be at least 5 seconds apart. You can batch write points to a time series, provided that the data points are written in order.
4 External metrics are those written to external.googleapis.com.
5 A time series is active if you have written data points to it within the previous 24 hours. The limit specified in the row is the total number of active time series for a single monitored resource (for example, a single gce_instance VM or a single k8s_container container) across all user-defined metrics within that row (custom, workload, Prometheus, or external). An exception is the global monitored resource, for which the limit applies to each user-defined metric separately. This is a system-wide safety limit and isn't customizable.

Monitoring API quotas and limits

Category Maximum value
Limits to API usage

To find the API quotas and limits, do one of the following:

Lifetime of API page tokens 24 hours

About Monitoring API quotas

The Monitoring API has quota limits for the rates of time-series ingestion requests and time-series queries. Ingestion requests are calls that write time-series data, and queries are calls that retrieve time-series data. There are also internal limits on other Monitoring API endpoints; these endpoints aren't intended to handle high rates of requests.

To reduce the number of API requests you issue when your services write time-series data, use one API request to write data for multiple time series. We recommend that you write at least 10 objects per request. For more information about batching API requests, see timeSeries.create.

If, after batching your API requests, you still require a higher Monitoring API quota limits, contact Google Cloud Support.

The other limits are fixed and as detailed on this page.

For more information, go to Working with quotas.

Data retention

Metric data points older than the retention period are deleted from time series.

Category Value
Retention of data points from custom, external, and agent metric types, including:
  • Custom metrics, prefix custom.googleapis.com
  • Metrics from Google Cloud Managed Service for Prometheus, prefix prometheus.googleapis.com2
  • Agent metrics, prefix agent.googleapis.com, including
    processes/count_by_state and processes/fork_state.
    The remaining processes metrics have a different retention period; see the following entry.
  • External metrics, prefix external.googleapis.com
  • OpenTelemetry and other workload metrics, prefix workload.googleapis.com
24 months1
Retention of data points from process-health metric types: agent.googleapis.com/processes,
except for count_by_state and fork_state, as noted in the previous entry.
24 hours
Retention of data points from all other metric types, including: 6 weeks
Lifetime of API page tokens 24 hours

1 Metric data is stored for 6 weeks at its original sampling frequency, then it is down-sampled to 10-minute intervals for extended storage.
2 Google Cloud Managed Service for Prometheus metric data is stored for 1 week at its original sampling frequency, then it is down-sampled to 1-minute intervals for the next 5 weeks, then it is down-sampled to 10-minute intervals for extended storage.

Resource groups

Category Value
Number of resource groups per metrics scope 500
Maximum number of groups included in an email report1 10

1 When you configure Cloud Monitoring email reports, you can request information on utilization of your resource groups. Due to a limitation in the email reporter, the generated reports include information for only 10 groups.

Monitored project limits

Cloud Monitoring officially supports up to 375 Google Cloud projects per metrics scope .

You can add up to 1,000 Google Cloud projects per metrics scope , but you might experience performance issues, especially when querying custom metrics or historical data. Cloud Monitoring guarantees performant queries and charts only for 375 Google Cloud projects per metrics scope .

To raise your Google Cloud projects per metrics scope quota, you can request an increase of the "Monitored Projects / Monitoring Metrics Scope" quota. See the documentation about managing your quota for more details.

Limits on creating and updating metric descriptors

Cloud Monitoring enforces a per-minute rate limit on creating new metrics, on adding new label names to existing metrics, and on deleting metrics. This rate limit is usually only hit when first integrating with Cloud Monitoring, for example when you migrate an existing, mature Prometheus deployment to Cloud Monitoring. This is not a rate limit on ingesting data points. This rate limit only applies when creating never-before-seen metrics or when adding new label names to existing metrics.

This quota is fixed, but any issues should automatically resolve as new metrics and metric labels get created up to the per-minute limit.

Limits for alerting

Category Value Policy type1
Alerting policies (sum of metric and log) per metrics scope 2 500 Metric, Log
Conditions per metric-based alerting policy 6 Metric
Conditions per SQL-based alerting policy (Public Preview) 1 SQL
Maximum time period that a
metric-absence condition evaluates3
1 day Metric
Maximum time period that a
metric-threshold condition evaluates3
23 hours 30 minutes Metric
Maximum length of the filter used
in a metric-threshold condition
2,048 Unicode characters Metric
Maximum number of time series
monitored by a forecast condition
64 Metric
Minimum forecast window 1 hour (3,600 seconds) Metric
Maximum forecast window 2.5 days (216,000 seconds) Metric
Notification channels per alerting policy 16 Metric, Log
Maximum rate of notifications4 1 notification every 5 minutes for each log-based alerting policy Log
Maximum number of notifications 20 notifications a day for each log-based alerting policy Log
Maximum number of simultaneously open incidents
per alerting policy
1,000 Metric
Period after which an incident with no new data is
automatically closed
7 days Metric
Maximum duration of an incident if not manually closed 7 days Log
Retention of closed incidents 13 months Not applicable
Retention of open incidents Indefinite Not applicable
Notification channels per metrics scope 4,000 Not applicable
Maximum number of alerting policies per snooze 16 Metric, Log
Retention of a snooze 13 months Not applicable
1Metric: an alerting policy based on metric data; Log: an alerting policy based on log messages (log-based alerts)
2Apigee and Apigee hybrid are deeply integrated with Cloud Monitoring. The alerting limit for all Apigee subscription levels—Standard, Enterprise, and Enterprise Plus—is the same as for Cloud Monitoring: 500 per metrics scope .
3The maximum time period that a condition evaluates is the sum of the alignment period and the duration window values. For example, if the alignment period is set to 15 hours, and the duration window is set 15 hours, then 30 hours of data is required to evaluate the condition.
4If the query of your log-based alerting policy extracts label values, then each combination of extracted values represents its own notification timeline. For example, assume a log-based alerting policy extracts the values of a label. Assume that label can have two values. With this configuration, you could receive two notifications, one for each label value, in the same 5 minutes.

Limits for synthetic monitors

Category Value
Uptime checks per metrics scope * 100
Maximum number of ICMP pings per public uptime check 3
Synthetic monitors per metrics scope 100
*This limit applies to the number of uptime-check configurations. Each uptime-check configuration includes the time interval between testing the status of the specified resource.
For information about how to increase this limit, see Manage your quota using the Google Cloud console.

Limits for charting

Category Value
Dashboards per metrics scope 1000
Charts on a dashboard 40
Lines on a chart 50*
Rows in a table 300
*This limit is applied for performance reasons. When there more than 50 time series to chart, an icon with a red dot is added to the toolbar. The tooltip for the icon displays the message To improve performance, we've limited the time series displayed in this chart. To display all time series, expand the tooltip and select the button labeled Show All Time Series.

Service-level objectives

Category Value
Number of SLOs per service 500