Quotas and limits

To ensure efficient operation, Cloud Monitoring imposes the following usage limits.

Custom metrics

Category	Maximum value
Custom metric descriptors per project¹	2,000
Labels per metric descriptor	30
String length for label key	100
String length for label value	1024
Time series included in a request²	200
Rate at which data can be written to a single time series³	one point each 5 seconds
Histogram buckets per custom distribution metric	200
Workload, Prometheus, and external⁴ metric descriptors per project	10,000
Active time series from custom metrics per monitored resource⁵	200,000
Active time series from workload metrics per monitored resource⁵	200,000
Active time series from Prometheus per monitored resource⁵	1,000,000
Active time series from external metrics per monitored resource⁵	200,000

¹ This limit is imposed by Cloud Monitoring. Other services might impose lower maximum values.
² 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.
³ 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.
⁴ External metrics are those written to external.googleapis.com.
⁵ 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 across all metric types for that row (custom, workload, Prometheus, or external), for a single monitored resource. An exception is the global monitored resource, for which the limit applies to each metric type separately. This is a system-wide safety limit and isn't customizable.

Monitoring API quotas and limits

Category	Maximum value
Limits to API usage	See the Quotas dashboard. For an API, click All Quotas to see your quota.
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` Workload metrics, prefix `workload.googleapis.com` Metrics from Google Cloud Managed Service for Prometheus, prefix `prometheus.googleapis.com` 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`	24 months^†
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: Google Cloud metrics Kubernetes metrics Anthos metrics Istio metrics Logs-based metrics	6 weeks
Lifetime of API page tokens	24 hours

^† Metric data is stored for 6 weeks at its original sampling frequency, 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 report¹	10

¹ 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

You can add up to 375 Google Cloud projects per metrics scope . To request an increase of this limit, contact your account team.

Limits for alerting and uptime checks

Category	Value	Policy type¹
Alerting policies (sum of metric and log) per metrics scope ²	500	Metric, Log
Conditions per alerting policy	6	Metric
Maximum time period that a metric-absence condition evaluates³	1 day	Metric
Maximum time period that a metric-threshold condition evaluates³	23 hours 30 minutes	Metric
Notification channels per alerting policy	16	Metric, Log
Maximum rate of notifications	1 notification every 5 minutes for each log-based alert	Log
Maximum number of notifications	20 notifications a day for each log-based alert	Log
Maximum number of simultaneously open incidents per alerting policy	5000	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	4000	Not applicable
Uptime checks per metrics scope ⁴	100	Not applicable

¹Metric: an alerting policy based on metric data; Log: an alerting policy based on log messages (log-based alerts)
²Apigee 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 .
³The 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.
⁴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. See Managing uptime checks for more information.

Limits for charting

Category	Value
Dashboards per metrics scope	1000
Charts on a dashboard	40
Lines on a chart	300

Service-level objectives

Category	Value
Number of SLOs per service	500