How do I get alerted about a GCP spend spike programmatically?

Create a Cloud Billing budget and attach a Pub/Sub topic to it; Google publishes budget and threshold notifications to that topic, which you can route to Slack, Teams, or a Cloud Function. For anomaly-level detail (which service spiked, by how much, and a likely cause) rather than just a budget threshold, run a detector over the daily cost data in your BigQuery billing export and alert from that.

Why do anomaly tools miss gradual cost creep?

Most anomaly detectors continuously re-learn what 'normal' is, so a cost that ramps a few percent per day gets absorbed into the baseline and never trips an alert — even though it can add up to a large monthly increase. Catching creep needs a trend estimator, like a Theil–Sen slope over the last 30 days, rather than a point-in-time outlier test.

Google Cloud · Cost governance · July 2026

Google Cloud Cost Anomaly Detection: Catch Spend Spikes Early

Q: Does Google Cloud have cost anomaly detection?

Yes — Google Cloud surfaces cost anomalies in the billing console and the FinOps Hub, and Cloud Billing budgets can alert on thresholds and forecasted overspend with programmatic Pub/Sub notifications. These are free and worth enabling, but the anomaly view is newer and less configurable than a tuned detector, and budgets alert on totals rather than explaining which service or resource moved.

By the CloudFinOpsKit team. 8 min read.

The cheapest cost incident is the one you catch on day one, not on the invoice. Google Cloud gives you free tooling to spot spend spikes — cost anomaly views in the billing console and FinOps Hub, plus Cloud Billing budgets with Pub/Sub alerts — and you should turn them on. But they have blind spots, especially gradual creep and per-resource attribution. This is how the native tools work, where they fall short, and the auditable methodology that fills the gaps on GCP.

What Google Cloud gives you natively

Cost anomaly detection — Google surfaces anomalous spend in the billing console / FinOps Hub. Free and improving, but newer and less tunable than a detector you control, and there's no dollar-floor or sensitivity you set.
Cloud Billing budgets — set a budget and alert at thresholds (e.g. 50/90/100%) or on forecasted overspend. Attach a Pub/Sub topic for programmatic notifications you can route to Slack, Teams, or a Cloud Function.
BigQuery billing export — the granular daily cost data (by service, SKU, project, label) that any real detector should run on. Turn it on early; it also powers trend and allocation.

Enable all three. They're the always-on baseline. The question is what they don't catch.

Where the native tools fall short

Budgets alert on totals, not causes. A budget tells you the number crossed a line; it doesn't tell you which service or resource moved or by how much — you still open the console and dig.
Gradual creep hides. A workload ramping 3% a day rarely trips a model that continuously re-learns "normal" — the drift is absorbed. Log growth, snapshot sprawl and slowly scaling services live in this blind spot.
Limited tuning. You can't set an explainable dollar floor or a percentage threshold on the native anomaly view, so a noisy sandbox project and a production spike look similar.

An auditable methodology that fills the gaps

For governance you want a portable, explainable definition of "anomaly" — published thresholds you can recompute by hand, fed by the BigQuery billing export. That rules out black-box ML and points at deterministic robust statistics. Five detectors run over each service's daily cost (and a scope total):

Detector	The rule	What it catches
Daily spike	Day vs the median of its last ~8 same-weekday values; flag when the modified z-score (MAD-based) ≥ 3.5.	A runaway job, a retry storm, a data-transfer blow-out — weekday-aware, so weekends don't false-flag.
Step change	Median of the trailing 7 days vs the prior 21; flag a sustained shift ≥ 30%.	A deployment that permanently raised the run rate.
Gradual creep	Theil–Sen slope over 30 days; flag when drift projects to ≥ 20%/month.	The class the native anomaly view absorbs into "normal".
New spend source	A service with ~$0 history now averaging real money/day.	An accidental region/service — or, if unowned, possible compromise.
Vanished spend	An established service collapsing to ~0 (informational).	A decommission — or a broken workload masquerading as savings.

The two design decisions that make it trustworthy: a dual gate — every flag must clear both statistical significance and an absolute dollar floor, so penny-scale noise never pages anyone — and median + MAD robust statistics, so one past spike can't inflate the baseline and hide the next one. Because every number is published, any flag can be recomputed from the report.

This is the Cost Anomaly Watch in the tool. The CloudFinOpsKit tool runs exactly this methodology over your Google Cloud billing export — same detectors, same dual gate, same math as the Azure and AWS kits — and pushes High-severity anomalies to a webhook (or Pub/Sub) with expected-vs-actual, projected monthly impact, and a plausible-cause hint. Keep Google's native detection on as the baseline; this is the explainable, tunable layer that also catches creep. See the cross-cloud methodology for the full treatment.

FAQ

Does Google Cloud have cost anomaly detection?

Yes — in the billing console / FinOps Hub, plus budget alerts with Pub/Sub. They're free and worth enabling, but newer/less tunable than a controlled detector and they alert on totals rather than explaining which service moved.

How do I alert on a spike programmatically?

Attach a Pub/Sub topic to a Cloud Billing budget for threshold/forecast notifications; for service-level anomaly detail, run a detector over the BigQuery billing export and alert from that.

Why is gradual creep so easy to miss?

Detectors that re-learn "normal" absorb slow drift. Catching it needs a trend estimator (a Theil–Sen slope over 30 days), not a point-in-time outlier test.