Google Cloud budgets and billing alerts: the setup we put on every client project on day one

Say a 12-person logistics company runs two Cloud Run services and a nightly BigQuery job. Someone sets a budget of 300 dollars a month, ticks the alert boxes, and stops thinking about it. Six weeks later a retry loop runs all weekend and the invoice lands at four figures. The budget did exactly what it was built to do, which is send email.

This is the most common cost mistake we find on a small company's Google Cloud project, and it is not carelessness. The word budget promises a ceiling. In Cloud Billing it mostly buys a notification.

What a budget alert does, and what it does not

A Cloud Billing budget watches the cost of a scope you choose and sends notifications when spend crosses your thresholds. Google's documentation is blunt about the limit: budget alert emails might prompt you to take action to control your costs, but they do not automatically prevent the use or billing of your services when a threshold is met or exceeded. An alerts-only budget does not cap usage or spending.

A budget alert is a smoke detector. It tells you something is burning. It does not put the fire out. It is still worth setting up properly, because most bad months are visible days before the invoice. What follows is the setup we leave behind, in the order we do it.

Which control actually stops the money

Most small companies need the first two and one of the last three.

Control	What it guarantees	What it does not do
Budget alert on actual cost	A notification when cumulative spend crosses a threshold	Stop anything. Charges keep accruing after the email
Budget alert on forecasted cost	A notification when the projection for the period crosses a threshold	Work on a custom time range. It needs a calendar period
Spend cap budget	Pauses one eligible service in one project once estimated cost passes 100 percent	Act instantly, cover every service, or count credits
Pub/Sub automation that unlinks billing	Stops the whole project, if you build and maintain the function	Spare anything. Free Tier stops too and resources are eventually deleted
A service's own quota or limit	A hard ceiling on that one resource, before any spend happens	Cover the rest of the project

The budget we put on a project on day one

Three decisions, independent of each other.

Scope. A budget can cover the whole billing account, or narrow to specific organizations, folders or projects, or to services such as Compute Engine or BigQuery. Labels narrow it further, one label per budget and only on billing-account-level budgets. For a small company we start with one budget per project, because a project is the unit an owner recognises.

Amount. Either a specified amount, a fixed figure your actual spend is compared against, or last period's spend, which resets each calendar period to 100 percent of the previous period. The dynamic option suits a steady workload and hurts a growing one, because one bad month quietly becomes next month's baseline.

Thresholds. A new budget arrives with alerts at 50, 90 and 100 percent of the amount, measured against actual spend. You can change them, add more, or remove them. Each rule is either actual cost, which fires on cumulative spend in the period, or forecasted cost, which fires when the projection for the end of the calendar period crosses the line. A budget on a custom time range cannot use forecasted thresholds at all.

We keep the three defaults and add one forecasted rule. The forecasted alert is the one that hands you a weekday to act on instead of a Sunday night surprise.

From the command line, thresholds are a repeatable flag where the percentage runs from 0.0 to 1.0 and the basis defaults to current spend:

gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="prod monthly" \
  --budget-amount=300USD \
  --threshold-rule=percent=0.50 \
  --threshold-rule=percent=0.75,basis=forecasted-spend

Scope filter flags differ between the stable, beta and alpha tracks, so check gcloud billing budgets create --help on the version you have installed.

Who gets the email, and why the owner usually does not

By default, budget alerts go to everyone holding Billing Account Administrator or Billing Account User, that is roles/billing.admin and roles/billing.user. For a budget scoped to a single project you can also send to that project's Owners, and you can attach up to five Monitoring notification channels, each referenced by its full resource name in the form projects/PROJECT_ID/notificationChannels/CHANNEL_ID. The default recipients can be switched off through disableDefaultIamRecipients in the API, with one exception: not on a spend cap budget.

Here is where it goes wrong in a small company. The person who cares most about the bill is the owner, who holds no billing role, so the alert lands with a developer who assumes someone else is watching. We add the owner as a Monitoring email channel and point a second copy at a shared inbox, so the alert survives a holiday and a resignation.

The only setting that actually pauses a service

Spend cap budgets do stop usage. Checked on 29 October 2026, Google's Cloud Billing release notes list them as generally available since 13 October 2026 for a limited set of services, after a Preview launch on 27 July 2026.

Once gross estimated usage cost passes 100 percent of the amount, usage of the specified service in that project pauses for the rest of the budget period. Resources and data are not deleted, and only that service pauses. The constraints matter when you plan around it:

• One project and one eligible service per budget, monthly period only, fixed amount rather than last period's spend.
• Eligible services in this release are the Gemini API, Agent Platform (formerly known as Vertex AI), Cloud Run and Cloud Run functions. Google says more will follow.
• Exactly three threshold rules, at 0.5, 0.8 and 1.0. Forecasted spend is not supported.
• Calculations use gross estimated costs at list price and exclude savings and credits.
• Enforcement is faster than billing reports but not instant, and any overage is billed as normal. Fixed commitment fees keep billing at their contractual rate, committed use discounts among them.
• The cap lifts on its own at the start of the next period. Lift it by hand and it will not trigger again that period unless you raise the amount.

For the logistics company in the opening that is a real answer: a spend cap on Cloud Run in that project. For a Compute Engine VM or a BigQuery job it is not available yet. If the workload is AI rather than web, the spend controls on the Gemini side are a separate layer.

The kill switch you build yourself, and why we rarely leave it on

Google documents the pattern: budget notifications to a Pub/Sub topic, and a Cloud Run function that calls the Cloud Billing API to unlink the billing account. It works, and we keep it off most small clients' production projects for four reasons.

1. It stops everything. Disabling billing stops every service in the project, Free Tier services included, and the documentation warns that resources are eventually deleted.
2. The function's service account needs Billing Account Administrator on the billing account, a broad permission to leave sitting in an automated path.
3. Notifications lag real usage, so charges accrue before anything stops. Google's own guidance says following the steps does not guarantee you stay under budget.
4. Pub/Sub discards messages when nothing is subscribed. If the function breaks, the topic goes quiet and nobody finds out until the invoice.

The narrow version suits most small companies better: let the notification stop named Compute Engine instances instead of cutting billing for the whole project. Google documents that variant too. We save the full switch for a sandbox or training project with no production data, where the worst case of a hard stop is an afternoon.

The bill you can query, not just read

Console reports answer how much. The BigQuery export answers which SKU, in which project, on which day, and that turns an alarming invoice into a ten-minute conversation. Two tables matter. The standard usage cost export, gcp_billing_export_v1_BILLING_ACCOUNT_ID, carries services, SKUs, projects, labels, cost, usage and credits. The detailed export, gcp_billing_export_resource_v1_BILLING_ACCOUNT_ID, adds resource-level cost down to a single VM or disk. Standard for trends, detailed for finding the resource that moved, and querying detailed can cost more, so point the daily dashboard at standard. We go into that trade in what a BigQuery bill actually charges for.

Two setup details catch people out. The export needs the Google-managed service account billing-export-bigquery@system.gserviceaccount.com to have access to the dataset. And the backfill depends on where the dataset lives: a multi-region dataset in the EU or US gets a first-time backfill, while one in a single supported region only holds data from the day you enabled the export forward, with no retroactive fill later. That is the whole argument for turning the export on at the start of a project rather than the first time something goes wrong. You cannot buy the history back.

Cost and risk notes

A spend cap pauses a service, and for anything customer-facing a pause is an outage. Set the amount where an outage genuinely beats the bill, and not a dollar lower. On a public Cloud Run service that number is usually higher than the owner's first instinct.

Alerts and caps both work on estimated figures. Actual costs in a budget are approximate charges accrued during the period and stay subject to change until the invoice is finalised, so treat a threshold as a signal and the invoice as the number. A cap also ignores savings and credits, so a project that looks comfortable on net spend can still trip one set from a net figure. And none of this replaces a per-service limit: a maximum instance count on a Cloud Run service or a custom quota on BigQuery stops spend before it happens, which a budget never does.

What we watch in the first month

• Whether the 50 percent alert actually arrived, and to whom. An alert nobody receives is the same as no alert.
• A forecasted alert firing early in the month. That usually means a workload changed, not that the budget is wrong.
• The top five SKUs from the detailed export at the end of week one. If nobody can name them, the project is not understood yet.
• Whether anything sitting behind a spend cap has moved into production since the cap was set.

How Guanacos Tech helps

We leave this on any Google Cloud project we run: one budget per project with the three actual thresholds plus a forecasted one, alerts routed to the people who pay the bill, the billing export landing in BigQuery from day one, and a spend cap where the service supports one. If you would rather not learn about a bad month on invoice day, our Google Cloud consulting for small teams starts with a review of the billing account you already have, and how we scope and price the work is on how we work. The call is 30 minutes and ends with a written list of what to change, whether or not you hire us.

Sources

• Create, edit, or delete budgets and budget alerts (Cloud Billing)
• Manage spend cap budgets (Cloud Billing)
• Cloud Billing release notes
• Disable billing usage with notifications (Cloud Billing)
• Control resource usage with notifications (Cloud Billing)
• Set up Cloud Billing data export to BigQuery
• gcloud billing budgets create (Google Cloud SDK reference)
• REST Resource: billingAccounts.budgets (Cloud Billing Budget API)