How to Set a Google Cloud Budget (and Actually Stop the Bill)

The thing nobody tells you: budgets are alerts, not limits

This is the single most expensive misunderstanding in Google Cloud. You go to Billing, create a budget, set it to $50, and reasonably assume that when you hit $50 something stops.

Nothing stops. A budget is a notification rule. It watches your spend and emails the billing account admins when you cross a threshold. Your resources keep running, and your bill keeps growing, whether or not anyone reads the email.

Google is explicit about this in its own documentation: if you are using budgets as a cost-control tool, email notifications might not be the best method to ensure timely action. That is a polite way of saying the alert will arrive at 2am on a Saturday and the runaway job will still be running on Monday.

There is also lag. Usage takes time to land in billing data, so you can cross your threshold and continue accruing charges before the alert fires. A budget will never be a precise ceiling.

Set the budget properly first

Even though it will not stop anything, a well-configured budget is the foundation for everything else.

1. 1

   Create the budget at the billing account, not the project

   Billing → Budgets & alerts → Create budget. Scope it to the whole billing account if this is your only project; scope per project once you have several, so you can tell which one moved.

2. 2

   Set multiple thresholds, not one

   Use 50%, 90% and 100% of actual spend. One alert at 100% tells you it already happened. A 50% alert halfway through the month tells you something changed while you can still act.

3. 3

   Add a forecasted-spend threshold

   Google can alert on projected end-of-month spend, not just actual. This is the one that catches a cost increase on day 3 rather than day 25, and it is the most useful alert of the set.

4. 4

   Point the budget at a Pub/Sub topic

   In the budget’s notification settings, enable Pub/Sub. This is what makes automated responses possible at all — without it you only have email, and email cannot take action.

5. 5

   Check who actually receives the email

   By default it goes to billing account administrators. If that is an alias nobody reads, the entire mechanism is decorative. Route it somewhere a human sees.

Building an actual hard stop

If you genuinely need spending to halt, the documented pattern is: budget → Pub/Sub topic → a function that disables billing on the project.

The budget publishes a message to Pub/Sub each time it evaluates. A Cloud Run function subscribes, checks the cost against the budget in the message, and if it has been exceeded calls the Cloud Billing API method `updateProjectBillingInfo` with `billingAccountName` set to an empty string. That detaches the billing account from the project.

The function’s service account needs `roles/billing.admin` on the billing account itself, not just on the project. That is a genuinely powerful permission, and granting it to an automated workload is a real decision, not a formality.

Safer controls that cap cost without destroying anything

For most people, the sensible setup is not a kill switch. It is a set of boundaries that make runaway spend impossible in the first place.

Quotas are the real limiter. Capping API request rates and the number of CPUs a project can allocate constrains the blast radius of a bug or a bad loop, without ever deleting anything. This is the control that budgets are mistaken for.

Cloud Run max instances deserves specific mention, because scale-to-zero cuts both ways: a service that scales to zero when idle will also happily scale to hundreds of instances under load, or under an accidental request loop. Setting a maximum instance count puts a genuine ceiling on that service’s cost.

Billing alerts on forecasted spend, as above, catch a trend early enough to be acted on.

And committed use discounts are the opposite problem — they lower your rate but commit you to spend, so they are the wrong tool when your goal is a low floor rather than a low rate.