Alerting overview
This document describes how you can get notified when your applicationfails or when the performance of an application doesn't meet definedcriteria.
How alerting works
The Cloud Monitoring alerting process contains three parts:
Analerting policy, which describes the circumstances under which you wantto be alerted and how you want to be notified about an incident.The alerting policy can monitor time-series data stored byMonitoring or logs stored by Cloud Logging.When that data meetsthe alerting policy condition, Monitoring creates anincident and sends the notifications.
Eachincident is a record of the type of data that wasmonitored and when the conditions were met. This informationcan help you troubleshoot the issues that caused the incident.
Anotification channel defines howyou receive notifications when Monitoring creates anincident. For example, you can configure an alerting policy to email
my-support-team@example.comand to post a Slack message to the channel#my-support-team. An alerting policy can contain one or more notificationchannels.
Alerting policies can evaluate three types of data:
Time-series data, also called metric data, which is stored byMonitoring. These types of policies are calledmetric-based alerting policies.
To learn how to set up a metric-based alerting policy, trytheQuickstart for Compute Engine.
Log entry data stored by Cloud Logging. Alerting policies that evaluateindividual log entries are calledlog-based alerting policies. Log-based alerting policiesnotify you when a particular message appears in your logs.For more information, seeMonitor your logs.
The results of a SQL query run inLog Analytics against log entrydata stored in Logging. Alerting policiesthat monitor the results of a SQL query are calledSQL-based alerting policies. For more information, seeMonitor your SQL query results with an alerting policy.
SQL-based alerting policies is in Public Preview.
The alerting process helps you respond to issues when the performance ofan application fails to meet acceptable values. For example, you deploy a webapplication onto a Compute Engine virtual machine(VM) instance. While you expect theHTTP response latency tofluctuate, you want your support team to respond when theapplication has high latency for a significant time period. You could create ametric-based alerting policy that monitors the application's HTTP responselatency metric. If the response latency is higher than two seconds for at leastfive minutes, then Monitoring creates an incident and sendsemail notifications to your support team.
How to create an alerting policy
There are multiple ways to create an alerting policy. For example, you canuse pre-configured alerting policies by enabling recommended alertsfrom integrations or certain pages in the Google Cloud console.You can also configure a new alerting policy by using theGoogle Cloud console, theCloud Monitoring API, theGoogle Cloud CLIandTerraform.
Use integrations and recommended alerting policies
Monitoring providespre-built packages to let you create alerting policies for yourGoogle Cloud services and third-party integrations. The packages includerecommended alerting policies, sample dashboards, and key metrics for theservice. These packages are available forGoogle Cloud services such as Google Kubernetes Engine, Compute Engine, and Cloud SQL,and common third-party integrations such as MongoDB, Kafka, andElasticsearch.
When you install a package, you can enable the package's recommended alertingpolicies. When you enable a recommended alerting policy, you configure itsnotification channel and optionally modify other values.After configuration, the alerting policy begins monitoring its targetimmediately, with no further user input required.
Recommended alerting policies are helpful when you've deployed a new serviceand want to alert on important metrics. For example, theCloud SQL integration package comes with recommended alerting policies forfailed instances and slow transactions:
For more information on alerting integrations,seeMonitoring third-party applications.
Create new alerting policies
You can create alerting policies to monitor different types of data depending onyour alerting needs. The following sections list the different typesof data that you can monitor with alerting policies.
Monitor time series data
| Condition Type | Description | Example |
|---|---|---|
| Metric-threshold condition | Metric-threshold conditions are met when the values of a metric are more than, or less than, a threshold for a specific retest window. For more information, seeCreate metric-threshold alerting policies andCreate alerting policies by using the API. | You want an alerting policy that sends a notification when response latency is 500ms or higher for five consecutiveuptime checks over 10 minutes. |
| Metric-absence condition | Metric-absence conditions are met when a monitored time series has no data for a specific retest window. The maximum retest window is 23.5 hours. For more information, seeCreate metric-absence alerting policies andCreate alerting policies by using the API. | You want an alerting policy that opens an incident with your support team when a resource doesn't respond to any HTTP requests over the course of five minutes. |
| Forecasted metric-value condition | Forecasted metric-value conditions are met when the alerting policy predicts that the threshold will be violated within the upcoming forecast window. The forecast window can range from 1 hour to 7 days. For more information, seeCreate forecasted metric-value alerting policies andCreate alerting policies by using the API. | You want an alerting policy that opens an incident with your support team when a resource is likely to reach 80% disk space usage within the next 24 hours. |
Monitor log entry data
To monitor individual log entries, use a log-based alerting policy.A condition on a log-based alerting policy is met when the alertingpolicy detects that a phrase from a log entrymatch the alerting policy criteria. For example, you want an alerting policythat opens an incident with your supportteam when a log entry'smessagecontainsproduct_ids=['tier_1_support', 'tier_2_support'].
For more information, seeConfigure log-based alerting policies in theLogging documentation.
Monitor SQL query results
To monitor SQL query results, use a SQL-based alerting policy.The condition of a SQL-based alerting policy periodically analyzesyour log entry data and then create incidents when the table of queryresults meets certain criteria. This type of alerting policy is helpful when youneed an alerting policy that monitors aggregations of data or complex patternsacross multiple log entries. For example, you want to get notified when morethan 50 log entries in the last 60 minutes have a severity ofWARNING.
For more information, seeMonitor your SQL query results with an alerting policy in theLogging documentation.
Alerting policy components
Each alerting policy has the following components:
A condition that describes when a resource, or a group ofresources, is in a state that requires you to respond. The conditionincludes the data source, a static or dynamic threshold, and data aggregationmethods such as filters and groupby. Your conditions canmonitor a single metric, multiple metrics, or a ratio of metrics. You can alsouse thePrometheus Query Language (PromQL) toinclude complex expressions such as dynamic thresholds andconditional logic.
If you use an integration to enable a recommended alerting policy,then the alerting policy condition is pre-populated.
A list of notification channels that describe who to notify when action isrequired. For more information, seeCreate and manage notification channels.
Documentation that appears in notifications and incident pages. Youcanconfigure the subject line of a notification, and you canadd helpful information to the body of the notification. For example, youmight configure the notification to display links to internal playbooks orto Google Cloud pages such as custom dashboards.For more information about documentation, including examples, seeAnnotate incidents with user-defined documentation.
Query languages
Use Prometheus Query Language (PromQL) and filters in your alerting policiesto take greater control over your metric evaluation. Monitoringsupports the following query types:
PromQL is a functional query language usedto evaluate time series data in real time. You can configure alerting policiesto includea PromQL query in their condition. Your PromQL queries can use anyvalid expression, such as metric combinations,ratios, and scaling thresholds. By configuring PromQL-based alertingpolicies in Google Cloud, you can reduce dependencies onexternal alerting infrastructure. For more information, seePromQL in Cloud MonitoringandPromQL alerting overview.
Monitoring filters let you configure alerting policiesto use filter-based metric ratios. Filter-basedalerting policies can't be viewed or modified in the Google Cloud console.For an example of a policy that uses Monitoring filters, seeMetric ratio.
Manage alerting policies and incidents
After an alerting policy is enabled, Monitoringcontinuously monitors the conditions of that policy. You can't configure thealerting policy to monitor conditions only for certain time periods. If you wantto disable the alerting policy for a certain time period, then create asnooze.
If an incident is open and Monitoring determines that theconditions of the metric-based policy are no longer met, thenMonitoring automatically closes the incident and sends anotification about the closure.
Pricing
To learn about pricing for Cloud Monitoring, see theGoogle Cloud Observability pricing page.
For information about how to monitor the number of trace spans or logs thatare ingested, or how to be notified when specific content is includedin a log entry, see the following documents:
What's next
For information about notification latency and how the choices for theparameters of an alerting policy affect when notifications are sent,seeBehavior of metric-based alerting policies.
For a list of metric-based policy examples, seeSummary of example alerting policies.
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2026-02-19 UTC.