Google Cloud adds long-lookback PromQL alert policies

Google Cloud has added long-lookback alert policies for PromQL in Cloud Monitoring. The preview feature extends alert queries across up to two years of stored metric data.

The update is aimed at users who rely on PromQL alerting and want to compare current behaviour with historical patterns rather than fixed thresholds. The longer lookback period supports year-on-year and quarter-on-quarter analysis within Cloud Monitoring.

Static thresholds are widely used in monitoring systems, but they can become less reliable as workloads change. A threshold set for one traffic level may produce too many alerts after growth, while separate policies for different workloads can add operational overhead.

The new option lets teams define alerts against a metric's own history. For example, an alert could fire when the average over the last five minutes is double the average over the last week, rather than when a metric crosses a single preset number.

Dynamic thresholds

This approach is designed to let alerting adapt as workloads rise or fall over time. It also addresses cases where a metric follows a regular daily or weekly pattern, making a single fixed threshold difficult to use.

Google outlined several methods users can apply in PromQL. One is a moving-average model, in which recent data is compared with a longer baseline, such as the prior week. Another uses a z-score, comparing recent values with the historical average and standard deviation to identify abnormal behaviour relative to normal volatility.

A third method relies on time offsets. In that setup, a team can compare the last five minutes of activity with the same period a day or a week earlier. This is intended for metrics that rise and fall at predictable times, such as website traffic during business hours.

Users should choose an approach based on the shape of their data. Metrics with little variation may suit a moving average or z-score, while those with pronounced time-of-day or day-of-week swings may be better served by offset comparisons.

Google also warned that dynamic thresholding based on historical data may be less reliable for highly granular alerts on new workloads. In those cases, limited historical data can make alerts unstable until more information accumulates. One way to reduce that problem is to apply such alerts to aggregate metrics instead.

Operational use

The announcement also highlighted cost control as a practical use case. Google described a scenario in which a company monitors AI token use and creates an alert if token consumption over the last 10 minutes rises to 25 times the one-week historical average.

In that example, the alert would be sent through a Pub/Sub notification channel to a Cloud Run function. The function would then trigger a workflow that uses the Cloud Quotas API to reduce token usage quota to zero, stopping further spend until the issue is resolved.

Such a setup could help contain incidents such as leaked API keys or other extreme anomalies that lead to abrupt increases in usage. While legitimate traffic would also be paused, the aim is to stop the overspend immediately.

Limits and caveats

Google noted that time-offset alerts should generally track either drops or spikes, but not both in the same policy. If a sudden traffic drop is used as the historical baseline a day later, a return to normal activity can appear as a false spike, potentially triggering a second alert despite no new incident.

That means teams using seasonal comparisons may need more narrowly defined policies depending on the type of anomaly they want to catch. The guidance reflects one of the practical trade-offs in moving from fixed thresholds to history-based alerting.

The launch adds to a broader shift among cloud providers and observability vendors toward anomaly-based monitoring, particularly as customers manage larger numbers of services and more variable workloads. By exposing longer historical windows inside PromQL, Google gives users a way to build those models directly in Cloud Monitoring rather than relying solely on static rules.

The feature currently applies to PromQL alert policies in Cloud Monitoring and supports analysis across two years of metric data stored in the service.