Google Cloud budgets cost nothing and stop nothing by themselves: a budget compares the actual or forecast cost of a scope with an amount, sends emails at the thresholds you set and can publish its state to a Pub/Sub topic several times a day for anything that acts on it; the only budget that enforces is the spend cap budget, which pauses the eligible services of a project for the rest of the period once the estimated cost at list price passes the cap. Recommender delivers cost recommendations per project from the usage it observes, idle and oversized instances, idle disks and addresses, commitments to buy, BigQuery slots and partitioning, Cloud SQL and Cloud Run sizing, free of charge and at list prices. What makes any of it effective is reach, not price: a budget alert follows the billing data's delay, a forecast is Google's model of the month, and a recommendation is a saving at list price that your discounts and commitments may change.
Pricing dimensions
The table lists the mechanisms as dimensions: what each checks, in which scope, what it triggers and what it cannot do. The cross-provider concept is in budgets, the threshold logic in budget alerts and thresholds.
| Mechanism | Scope and basis | What it triggers | What it cannot do |
|---|---|---|---|
| Budget, alerts only | A billing account, one or more organisations, folders or projects, services and resources with a label; a monthly, quarterly, yearly or custom period; an amount you set or the previous period's spend; credits included or excluded; free | Threshold rules as percent of the budget on actual or forecast cost, by default at 50, 90 and 100 percent of actual; emails to billing administrators and users or to Monitoring notification channels; a Pub/Sub message with the state several times a day | Stops nothing; follows the billing data's delay; one budget per currency and scope |
| Spend cap budget | A project linked to the billing account, for the services eligible for it; estimated cost at list price without credits | Pauses the eligible services for the remainder of the period when the cap is reached; lifted automatically at the next period or by hand | Covers eligible services only; counts list price, so the cap trips before the discounted bill reaches it; a paused service loses its state where it has one |
| Programmatic notification | Any alerts-only budget connected to a Pub/Sub topic | A JSON message with costAmount, budgetAmount, budgetAmountType, alertThresholdExceeded and forecastThresholdExceeded, published repeatedly through the day | Nothing by itself; the Cloud Run function or workflow behind the topic acts, including the disable-billing pattern that detaches the project's billing account and stops everything in it |
| Forecast | Google's projection of the period's cost from the usage so far | Forecast threshold rules fire before the money is spent | A model, not your plan; new projects without history get no forecast |
| Recommender, cost category | Per project, from observed usage: idle VM, VM machine type rightsizing, idle Persistent Disk, idle IP address, idle custom image, resource-based and spend-based committed use discounts, Cloud SQL idle and overprovisioned instance, Cloud Run CPU allocation, BigQuery slot commitments and partitioning, Cloud Storage soft delete | A recommendation with an estimated saving at list price, in the console, the API and the Recommender export to BigQuery | Savings at list price without your discounts; no recommendation without utilisation history; applies nothing without a human or an automation |
| Active Assist | The portfolio of recommenders and insights across cost, security, performance and reliability | The same recommendations in one place per project and organisation | A view, not an action |
| Purchase options | The commitment recommenders lead into the purchase | Google Cloud committed use discounts | The purchase is a decision of the commitment strategy |
A budget is a comparison, not a control: it reads the billing account's cost data, which arrives with the export's delay, compares the sum for its scope with the amount, and sends an email or a message when a threshold rule fires; whether the message is read or acted on is the organisation's, and the spend cap budget is the one form that acts, by pausing services, which is why Google limits it to eligible services and a project scope. The forecast rule is the one that warns before the money is gone, because the actual rule fires after it. Recommendations are observations at list price: an idle VM is one with low CPU and network over a window, a rightsizing one with a smaller machine type that fits the observed load, a commitment one with a baseline worth committing, and each carries a saving computed from list prices, so an organisation with discounts or commitments recomputes before it acts. The mechanics of the AWS and Azure counterparts are in Budgets and Cost Anomaly Detection and Azure Advisor, budgets and cost alerts; the tool itself in Google Cloud billing reports.
Invoices, exports and APIs
Invoices. None of these mechanisms appears on the invoice or changes it; budgets and recommendations are free. A budget reads the same cost the invoice will carry, in the billing account's currency, with or without credits as configured; a spend cap counts the estimated cost at list price, which is higher than the discounted cost the invoice shows, so a cap set at the invoice amount trips early. Which account a budget belongs to and what it can see is in Google Cloud billing accounts, projects and labels.
Exports. The billing export to BigQuery is the data a budget compares; a budget on a label reads labels and project.labels, a budget on a folder the project.ancestry_numbers, and a report that reconciles a budget's state with the export groups the same rows the same way (the Google Cloud billing export). Recommendations have an export of their own: the Recommender export to BigQuery lists every recommendation and insight per project with its state, priority and estimated saving, which is how a portfolio of recommendations is tracked over time rather than read in the console. The delay between usage and the budget's view is the export's, described in data freshness in reports.
APIs. The Cloud Billing Budget API creates and lists budgets and their threshold rules; the Pub/Sub topic carries the state to a Cloud Run function, a workflow or a chat channel; the Recommender API lists, marks and applies recommendations per recommender and project, and the gcloud recommender commands do the same. The disable-billing pattern, a function that calls the Cloud Billing API to detach the project's billing account when a threshold fires, is Google's documented way to stop a project's spend, and it stops everything in the project, including the data the paused services hold.
Levers
Configuration: one alerts-only budget per project or folder with a rule on the forecast and one on actual cost, because the forecast warns and the actual proves; a Pub/Sub topic on the budgets whose state something acts on, because email is read after the fact; and the spend cap on projects whose services are eligible and whose state can be lost, sandboxes and experiments, not production. Recommendations become a monthly list: the Recommender export per project, filtered to cost, sorted by saving, with the discounts recomputed, feeds the review in guardrails and approval thresholds and the loop in rightsizing and idle and orphaned resources.
Purchase option: the commitment recommenders are a start, not an order; they compute at list price and per billing account, and the baseline they propose is the measured one, which the commitment strategy then halves or doubles by its own rules.
Architecture: budgets follow the hierarchy, a folder budget for a business unit and a project budget for a team, so an overrun shows twice; the spend cap budget on every sandbox project from creation, because a sandbox is where the unbounded spend starts; and a quota on the services that scale, because a budget alert arrives hours after the usage and a quota stops it at the limit. The budgets in Costfluent run on the export and are independent of the budgets in Google Cloud; what carries a forecast is in forecasting methods, how an anomaly is found without a budget in anomaly detection.
Where it goes wrong
- The budget emailed, nobody read it. An alerts-only budget sends email to billing administrators by default, who are not the team. Monitoring notification channels or a Pub/Sub topic to the team's chat are the fix.
- The alert came after the weekend. Budgets follow the billing data's delay; a runaway job on Friday night shows on Monday. A quota on the service, or a spend cap, is the control that acts in time.
- The spend cap tripped at 80 percent of the invoice. The cap counts list prices without credits; an account with discounts reaches it before the discounted cost does. Set the cap on list-price terms.
- The paused service lost its state. A spend cap pauses eligible services and some of them discard what they held. Spend caps on projects whose state is disposable.
- The disable-billing function deleted production. Detaching the billing account stops every service in the project and lets Google reclaim resources. The pattern belongs on sandboxes, never on a project that must survive the month.
- The recommendation's saving was at list price. An idle VM recommendation estimates the saving at list; with a committed use discount in place the instance's cost was already covered, and deleting it leaves the commitment unused. Recompute before acting.
- No forecast on the new project. A project without history gets no forecast and its forecast rule never fires. An actual rule at a low percentage covers the first month.
Example
A set-up example with Google's documented defaults and limits, without amounts: for a production project an alerts-only budget is created on the billing account with the project as its scope, a monthly period and a specified amount, credits excluded so the budget tracks the gross cost; its threshold rules are the default 50, 90 and 100 percent of actual cost, plus a rule at 100 percent of forecast cost that fires before the money is spent; the notifications go to a Monitoring notification channel that posts to the team's chat rather than to the billing administrators' email, and a Pub/Sub topic connected to the budget carries costAmount, budgetAmount and the thresholds exceeded to a Cloud Run function that opens a ticket. For a sandbox project the same budget is created as a spend cap budget on the eligible services, which pauses them for the rest of the month when the estimated cost at list price reaches the amount and lifts the cap at the start of the next month. In the console, the Recommender's cost category for both projects lists the idle VMs, the oversized machine types, the unattached disks and the idle addresses with their savings at list price, and the resource-based commitment recommender proposes a baseline for the production project, which the team recomputes with its discounts before the review. The example shows that the defaults decide the first version, that the forecast rule is the one that warns in time, and that the spend cap is the only budget that stops anything.
Sources
Read on 2026-10-22. Google Cloud documentation: create, edit or delete budgets and budget alerts, set up programmatic budget notifications, manage spend cap budgets, recommenders, export Cloud Billing data to BigQuery.