Is there a hard spending cap on Firebase once you leave the free tier? Budget alerts do not stop anything Cap it

There is no hard cap, and it is deliberate rather than an oversight. The stated reasoning in the docs is that they cannot distinguish a runaway loop from unexpected growth, so they do not turn your services off on your behalf.

The documented pattern is to wire the budget notification to Pub/Sub and run a function that disables billing on the project when a threshold is crossed. That is a real stop, not a notification.

Understand the tradeoff before you build it. It takes the project down. For a side project that is exactly right, an outage is much better than an invoice you cannot pay. For anything with customers it is not, and you want throttling at the application layer instead. Also note it inherits the same reporting delay as the alert, so it is a backstop, not a tripwire.

The protections that have actually saved me are all at the application layer, because they stop the loop rather than the invoice:

• App Check, so unknown clients cannot hammer your backend at all
• limits in your security rules, so an unbounded query is not expressible
• mandatory pagination, never an open ended collection fetch from a client
• a guard on anything recursive or retrying, especially a function that writes to a collection it also triggers on

That last one is the classic runaway bill: a trigger that fires itself. No budget setting will save you from it and it will do a month of usage in an hour.

The thing that bites people is rarely the feature they just launched. It is the background stuff: retries with no backoff, a scheduled job that overlapped itself, a listener left attached, storage that only ever grows.

Cheapest habit that has caught all of mine: a daily cost email, broken down by service, arriving in the morning. It does not prevent anything, but it means a bad night is a bad morning instead of a bad month, and after a fortnight you know your own normal well enough that anything odd is obvious at a glance.

Worth checking whether the specific services you use expose an editable quota in the Cloud console. Where a service does let you set a lower quota, that behaves like a ceiling in a way that a budget does not, because it is enforced at the API rather than reported after the fact.

Coverage varies by service, so do not assume it exists for everything in your stack. Look up each one you actually depend on, and where it exists, set it slightly above your real peak. Where it does not, fall back to the application layer limits.

Just set the budget to $5 and it stops there. That is what a budget is for.