To ensure efficient operation, Cloud Monitoring imposes the following usage limits.
Custom metrics
| Category | Maximum value |
|---|---|
| Custom metric descriptors per project1 | 2,000 |
| Labels per metric descriptor | 10 |
| String length for label key | 100 |
| String length for label value | 1024 |
| Time series included in a request2 | 200 |
| Rate at which data can be written to a single time series3 | one point each 10 seconds |
| Histogram buckets per custom distribution metric | 200 |
| External4 metric descriptors per project | 10,000 |
| Active time series from custom metrics per monitored resource5 | 200,000 |
| Active time series from external metrics per monitored resource5 | 200,000 |
1
This limit is imposed by Cloud Monitoring. Other services
might impose lower maximum values.
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 10 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.
These metrics include those written by Prometheus, which is a monitoring tool
often used with Kubernetes.
See Using Prometheus for more information.
5
A time series is active if you have written data points to it
within the previous 24 hours.
For custom and external metrics, including Prometheus3 metrics, the
limit applies to the total number of active time series across all custom metric
types, or across all external metric types, 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 and external metric types† | 24 months |
| Retention of data points from process-health metric types‡ | 24 hours |
| Retention of data points from all other metric types | 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. Custom metrics contain the prefix "custom.googleapis.com".
External metrics contain the prefix "external.googleapis.com".
‡ Process-health metrics are the
agent.googleapis.com/agent/processes
metrics that don't include count_by_state or
fork_count in the metric-type string. The
count_by_state and fork_count metrics are retained for
6 weeks.
Resource groups
| Category | Value |
|---|---|
| Number of resource groups per Workspace or 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
You can add up to 375 Google Cloud projects per Workspace or per metrics scope .
Limits for alerting and uptime checks
| Category | Value |
|---|---|
| Uptime checks per Workspace or per metrics scope 1 | 100 |
| Alerting policies per Workspace or per metrics scope 2 | 500 |
| Conditions per alerting policy | 6 |
| Notification channels per alerting policy | 16 |
| Notification channels per Workspace or per metrics scope | 4000 |
| Simultaneously open incidents per alerting policy | 5000 |
| Maximum duration for a metric-absence condition | 1 day |
| Maximum duration for a metric-threshold condition | 23 hours 30 minutes |
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 Workspace or per metrics scope .
Limits for charting
| Category | Value |
|---|---|
| Dashboards per Workspace or 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 |