A working GCP spend review is a cadence of three nested loops, each answering a different question on a different clock. The weekly loop asks what moved, catching anomalies while they are small using the billing export and budget alerts. The monthly loop asks whether spend is tracking forecast, how well committed use discounts are being used, and what sits in the rightsizing backlog. The quarterly loop asks whether the forecast, the commitment coverage strategy, and the architecture still make sense, and this is where the structural savings are decided. The loops only work when each line of spend has an engineering owner who can act, fed from a detailed billing export rather than the console summary. Run all three and cost stays controlled; skip the weekly loop and you discover problems on the invoice, skip the quarterly loop and you optimise noise while the cost floor stays where it was.
Here is what each loop checks, who owns it, and the numbers that should trigger action.
What should the weekly review catch?
The weekly loop exists to catch anomalies before they compound. A single misconfigured job, an accidental high tier network egress path, or a runaway BigQuery query can add meaningful cost in days, and finding it on the monthly invoice means paying for weeks of it. The weekly check reviews the billing export for any project, service, or label group whose daily run rate has stepped up against its recent baseline, and triages each: expected because of a launch, or unexpected and worth a question to the owning team. Budget alerts in Cloud Billing give you the automated backstop, firing when a project crosses a threshold of its budget, but a human scan of the top movers catches the increases that are still within budget yet clearly wrong. The trigger to act is simple: any movement the owning team cannot immediately explain gets investigated the same week, because an unexplained step up is the cheapest problem you will ever fix and the most expensive one to ignore.
What belongs in the monthly review?
The monthly loop is about variance and utilisation. Compare actual spend against the forecast by team and by service, and explain any line that is materially over or under, since a large underrun can signal a stalled project just as an overrun signals waste. Review committed use discount utilisation: a commitment that is not being fully consumed is paying for capacity you are not using, and one that is fully consumed with on demand spilling over on top is a signal to consider more coverage. Walk the rightsizing backlog from the recommenders, deciding which oversized instances, idle persistent disks, and unattached IP addresses get actioned this month and by whom. Check that sustained use discounts, which apply automatically to eligible Compute Engine usage, are landing as expected. The monthly review produces a short list of decisions with owners and dates, not a dashboard, because the value is in the actions agreed, not the data displayed.
A Fortune 500 retailer ran GCP cost reporting monthly off the Cloud Billing console and discovered most problems only on the invoice. We moved them to the three loop cadence: a weekly top mover scan off the BigQuery billing export with budget alerts as backstop, a monthly variance and commitment utilisation review with named owners, and a quarterly forecast and architecture review. In the first quarter the weekly loop caught two runaway query patterns and an oversized non production cluster within days rather than weeks, and the monthly loop cleared a rightsizing backlog the team had never scheduled. Steady state GCP spend fell by close to a third and stopped drifting back, because every saving now had an owner and a review that checked it held. The figures are verified against billing data and anonymised.
What does the quarterly review decide?
The quarterly loop is where the cost floor is reset. It revisits the forecast for the next few quarters using the trend the monthly loops have built, then sets commitment coverage against that forecast rather than against last quarter's usage, because committing to a defensible forward demand is the whole point of risk adjusted coverage. It reviews the architecture decisions that set the floor: whether BigQuery should move workloads from on demand to capacity pricing, whether a service should shift between Cloud Run and GKE on cost grounds, whether network tiers are right, and whether data lifecycle rules are tiering storage as they should. These are the decisions that change the structural cost, and they belong on a quarterly clock because they take planning and cannot be churned weekly. The quarterly review also audits the cadence itself: are labels still complete, does every major line still have an owner, and did last quarter's decisions actually land. A cadence that does not review its own discipline quietly decays.
Frequently asked questions
How often should you review GCP spend?
What data source should the GCP spend review use?
Who should own the GCP spend review?
Set up a GCP spend review that holds
We stand up the GCP review cadence, from the BigQuery billing export and label model to the weekly, monthly, and quarterly loops with owners and triggers, so savings stick instead of drifting back. We take zero provider commissions and answer only to you, and our guarantee is plain: we reduce your cloud spend or we reimburse our service fee, on either a Fixed Fee or a no risk Gainshare basis. Book a strategy call to scope it, and follow more in The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.