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. Quotas are defined by Trusted Cloud by S3NS services such as
Cloud Monitoring.
- System limits are fixed values that cannot be changed.
Trusted Cloud by S3NS uses quotas to help ensure fairness and reduce
spikes in resource use and availability. A quota restricts how much of a
Trusted Cloud resource your Trusted 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
Trusted Cloud users by preventing the overloading of services. Quotas also
help you to manage your own Trusted Cloud resources.
The Cloud Quotas system does the following:
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 Trusted Cloud project
level. Your use of a resource in one project doesn't affect
your available quota in another project. Within a Trusted Cloud project, quotas
are shared across all applications and IP addresses.
To adjust most quotas, use the Trusted Cloud console.
For more information, see
Request a quota adjustment.
There are also system limits on Monitoring resources.
System limits can't be changed.
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 |
Data retention
Metric data points older than the retention period are deleted from time series.
| Category |
Value |
Retention of data points for some Trusted Cloud by S3NS services, including most
metrics within the following categories:
- Compute Engine metrics, prefix
compute.googleapis.com
- GKE metrics, prefix
kubernetes.io
- Cloud Storage metrics, prefix
storage.googleapis.com
- BigQuery metrics, prefix
bigquery.googleapis.com
- Cloud SQL metrics, prefix
cloudsql.googleapis.com
|
24 months1
|
| Retention of all other Trusted Cloud by S3NS metrics |
6 weeks |
| Lifetime of API page tokens |
24 hours |
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-25 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[],[],null,["# Cloud Monitoring quotas and limits\n\nThis document lists the quotas and system limits that apply to\nCloud Monitoring.\n\n- *Quotas* specify the amount of a countable, shared resource that you can use. Quotas are defined by Google Cloud services such as Cloud Monitoring.\n- *System limits* are fixed values that cannot be changed.\n\nGoogle Cloud uses quotas to help ensure fairness and reduce\nspikes in resource use and availability. A quota restricts how much of a\nGoogle Cloud resource your Google Cloud project can use. Quotas\napply to a range of resource types, including hardware, software, and network\ncomponents. For example, quotas can restrict the number of API calls to a\nservice, the number of load balancers used concurrently by your project, or the\nnumber of projects that you can create. Quotas protect the community of\nGoogle Cloud users by preventing the overloading of services. Quotas also\nhelp you to manage your own Google Cloud resources.\n\nThe Cloud Quotas system does the following:\n\n- Monitors your consumption of Google Cloud products and services\n- Restricts your consumption of those resources\n- Provides a way to [request changes to the quota value](/docs/quotas/help/request_increase) and [automate quota adjustments](/docs/quotas/quota-adjuster)\n\nIn most cases, when you attempt to consume more of a resource than its quota\nallows, the system blocks access to the resource, and the task that\nyou're trying to perform fails.\n\nQuotas generally apply at the Google Cloud project\nlevel. Your use of a resource in one project doesn't affect\nyour available quota in another project. Within a Google Cloud project, quotas\nare shared across all applications and IP addresses.\n\nTo adjust most quotas, use the Google Cloud console.\nFor more information, see\n[Request a quota adjustment](/docs/quotas/help/request_increase).\n\n\nThere are also *system limits* on Monitoring resources.\nSystem limits can't be changed.\n\nUser-defined metrics\n--------------------\n\nThe Cloud Monitoring **Metrics Management** page provides information\nthat can help you control the amount you spend on billable metrics\nwithout affecting observability. The **Metrics Management** page reports the\nfollowing information:\n\n- Ingestion volumes for both byte- and sample-based billing, across metric domains and for individual metrics.\n- Data about labels and cardinality of metrics.\n- Number of reads for each metric.\n- Use of metrics in alerting policies and custom dashboards.\n- Rate of metric-write errors.\n\nYou can also use the **Metrics Management** page to\n[exclude unneeded metrics](/monitoring/docs/metrics-management#exclude-metrics),\neliminating the cost of ingesting them.\n\n\nFor more information about the **Metrics Management** page, see\n[View and manage metric usage](/monitoring/docs/metrics-management).\n\n^1^ This limit is imposed by Cloud Monitoring. Other services might impose lower maximum values. Custom metrics are those written to `custom.googleapis.com`.\n\n\n^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.\n\n\n^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.\n\n\n^4^ External metrics are those written to `external.googleapis.com`.\n\n\n^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.\n\nMonitoring API quotas and limits\n--------------------------------\n\nAbout Monitoring API quotas\n---------------------------\n\nThe Monitoring API has quota limits for the rates of time-series\ningestion requests and time-series queries. Ingestion requests are calls that\nwrite time-series data, and queries are calls that retrieve time-series data.\nThere are also internal limits on other Monitoring API endpoints;\nthese endpoints aren't intended to handle high rates of requests.\n\nTo reduce the number of API requests you issue when your services write\ntime-series data, use one API request to write data for multiple time series.\nWe recommend that you write at least 10 objects per request.\nFor more information about batching API requests, see\n[`timeSeries.create`](/monitoring/api/ref_v3/rest/v3/projects.timeSeries/create).\n\nIf, after batching your API requests, you still require a higher\nMonitoring API quota limits, contact\n[Google Cloud Support](/support).\n\nThe other limits are fixed and as detailed on this page.\n\nFor more information, see the [Cloud Quotas documentation](/docs/quotas/overview).\n\nData retention\n--------------\n\nMetric data points older than the retention period are deleted from time series.\n\n^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.\n\n\n^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.\n\nResource groups\n---------------\n\n^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.\n\nMonitored project limits\n------------------------\n\nCloud Monitoring officially supports up to 375 Google Cloud projects\n[per metrics scope](/monitoring/settings).\n\nYou can add up to 3,500 Google Cloud projects per metrics scope ,\nbut you might experience performance issues, especially when querying custom\nmetrics or historical data. Cloud Monitoring guarantees performant queries\nand charts only for 375 Google Cloud projects per metrics scope .\n\nTo raise your Google Cloud projects per metrics scope quota, you can request an\nincrease of the \"Monitored Projects / Monitoring Metrics Scope\" quota. See the\ndocumentation about [managing your quota](/docs/quotas/view-manage) for more details.\n\nLimits on creating and updating metric descriptors\n--------------------------------------------------\n\nCloud Monitoring enforces a per-minute rate limit on creating new metrics,\non adding new label names to existing metrics, and on deleting metrics.\nThis rate limit is usually only hit when first integrating with\nCloud Monitoring, for example when you\nmigrate an existing, mature Prometheus deployment to Cloud Monitoring. **This\nis not a rate limit on ingesting data points**. This rate limit only applies\nwhen creating never-before-seen metrics or when adding new label names to\nexisting metrics.\n\nThis quota is fixed, but any issues should automatically resolve\nas new metrics and metric labels get created up to the per-minute\nlimit.\n\nLimits for alerting\n-------------------\n\n^1^Metric: an alerting policy based on metric data; Log: an alerting policy based on log messages (log-based alerts) \n^2^You can request increases from the default of 2,000 per metrics scope up to 10,000. [Apigee](/apigee/docs) and [Apigee hybrid](/apigee/docs/hybrid/versions) 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: 2,000 per metrics scope . \n^3^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. \n^4^If the query of your log-based alerting policy extracts label values, then each combination of extracted values represents its own incident timeline. For example, assume a log-based alerting policy extracts the values of a label and that the label can have two values. With this configuration, two incidents can be created, one for each label value, in the same 5 minutes. \n^5^For log-based alerts, Monitoring sends a new notification for an open incident when a log entry that matches the filter is received and at least 5 minutes has elapsed since the most recent notification. At most 20 notifications per day per incident are sent. Each notification is sent to all configured notification channels for the alerting policy.\n\nLimits for SMS messages\n-----------------------\n\nThe SMS message limits are applied on a 24-hour rolling window.\n\nLimits for synthetic monitors\n-----------------------------\n\n^\\*^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. \n^†^For information about how to increase this limit, see [Request a quota adjustment](/docs/quotas/view-manage#requesting_higher_quota). \n\nLimits for charting\n-------------------\n\n^\\*^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**.\n\nService-level objectives\n------------------------"]]
