Google has introduced SQL-based alerting in Observability Analytics within Cloud Monitoring. The feature is in preview.
It lets users create alerts by running SQL queries over logs and traces, rather than relying only on fixed metrics or simple event thresholds. The approach is intended to help teams detect issues that appear in relationships across telemetry data, such as changes in error rates for a particular customer or latency patterns linked to other system events.
An alerting policy runs a user-defined SQL query on a chosen schedule. A lookback window limits the query to log entries or trace spans received since the previous run. If the results meet a set condition, Cloud Monitoring opens an incident and sends a notification through channels such as email, Slack, or PagerDuty.
Google is offering two trigger methods. One is a row count threshold, which sends an alert if a query returns more rows than a specified limit or falls above, below, or equal to a threshold. The other is a Boolean condition, which triggers an alert if any returned row contains a designated column with a true value.
The row count model is intended for cases where users want to spot a surge in a defined class of events. The Boolean model supports more complex logic, allowing users to calculate measures such as percentages directly in the query and decide whether those results should generate an alert.
Example Uses
One example focuses on payment gateway failures. A user can write a query to isolate failed transactions caused by gateway timeouts while excluding customer input errors such as an incorrect PIN, then trigger an alert if the number of affected rows rises above 10 over a five-minute period.
A second example centres on trace data for an AI orchestration service. In that case, a query calculates the 99th percentile latency for the service and returns a true or false value depending on whether latency exceeds 5,000 milliseconds, allowing the alert to fire when performance degrades.
SQL-based alerting uses BigQuery to process telemetry data. Query runs are billed through BigQuery under standard on-demand pricing or through BigQuery reservations, so users adopting the feature will need to account for additional query costs alongside their monitoring setup.
Setup Requirements
Before creating one of the new alerts, users need to enable analytics for the relevant telemetry source. For logs, that means upgrading a log bucket to use Observability Analytics if it has not already been updated. For traces, Cloud Trace data must be collected and stored in the project.
Users also need to create a linked BigQuery dataset for either the log bucket or the trace dataset, because SQL-based alerts run through that BigQuery connection. Access controls are another requirement: users need the Monitoring AlertPolicy Editor and Logging SqlAlert Writer roles to create the policies.
Notification channels must also be configured in advance so incidents can be delivered to operational teams. Once those steps are complete, users can compose and validate a SQL query in Observability Analytics, select the BigQuery query engine, and create an alert from the query results.
The alerts can also be managed through application programming interfaces and Terraform, allowing teams to incorporate them into infrastructure-as-code workflows rather than handling every alert manually in the console.
The move extends Google's broader push to make SQL a common interface for observability data. The company had already added SQL querying for logs and traces in Observability Analytics, and the new alerting feature builds on that by turning analytical queries into operational triggers.
For cloud operations teams, the release reflects a continuing shift in monitoring from static dashboards and predefined metrics toward more flexible analysis of raw telemetry. High-cardinality data such as user sessions, customer identifiers, and IP addresses has often been difficult to use in conventional alerting systems because fixed metrics can miss subtle anomalies or create large volumes of noise.
By allowing joins across logs and traces and the use of custom calculations in queries, the feature gives site reliability and platform engineering teams another way to define what constitutes an incident in their own environments. SQL alerting is now in preview.