How to avoid surprise Firebase bills: a checklist

Firebase has a page called Avoid surprise bills. It's a good start, and it covers three things: test your code, watch your usage, set up budgets. Below is the same ground as a checklist, in the same order, with what each step leaves open and the steps the page doesn't mention.

One thing to keep in mind from the start: "Firebase pricing plans apply to the entire project, not just to individual apps registered in the project." Every app in the project (web, iOS, Android, a test build pointed at production) adds to the same bill.

Google recommends the Local Emulator Suite, which runs Firestore, Cloud Functions, Realtime Database and more on your machine, so "you don't incur any Firebase costs that might result from testing against services in production". While you test, it names two patterns to look for:

• "Forgetting to add a limit to a database query with millions of results"
• "Combinations of Cloud Functions that cause excessive fan-out workloads or even infinite loops"

What it leaves open: the emulator shows what your code does, not what real users or a stranger will do with it. It won't catch a listener that subscribes again on every screen of the real app, or a bot calling your function. For the read patterns that slip past testing, see how to find what's reading your Firestore.

Google's second step: "You need to know what normal usage patterns look like for your app". Each product has a Usage tab in the Firebase console, and Settings, Usage and billing shows the whole project against the no-cost quota.

Two caveats. The numbers move at different paces: "Cloud Firestore and Cloud Storage usage are calculated daily" and "Cloud Functions usage is calculated monthly". And the Firestore dashboard is an estimate: "the dashboard is not an exact view of billed operations. Billed usage is likely higher." (Firestore usage docs).

What it leaves open: someone has to look. A dashboard shows a spike to whoever opens it, and at 3 a.m. nobody does. If a bill is already higher than expected, how to find what's billing you walks the billing reports down to the SKU and the day.

Upgrading to Blaze prompts you to create a budget. Do it, but read what it is: "Budget alerts do not pause services." They exist "so that you can take action, if needed".

What it leaves open: the alert arrives hours after the spend, and someone still has to act on it. Why, in Google's own words: why budget alerts don't stop your bill.

Spend cap budgets are the newer option: when a service reaches 100% of its budget, Cloud Billing "pauses that service for the rest of the month". They only cover Firebase AI Logic, App Hosting, Cloud Functions for Firebase and Extensions.

What it leaves open: Firestore, Realtime Database, Cloud Storage and Hosting aren't covered. And Google warns: "Spend caps are not "hard caps"." Enforcement "can be delayed by several minutes", and overages in that window are billed as normal.

Google's page is about watching costs. Most of the five-figure bills in our horror stories came from somewhere else: something outside the app calling paid services. Three things worth doing before launch:

• Restrict your API keys. Limit each key to the APIs and apps that need it, and keep the Gemini API off any key that ships in your app: how to restrict a Firebase API key.
• Turn on App Check and tight security rules. So only your app can reach your database and your callable functions: denial of wallet attacks.
• Cap your functions' instances. A runaway function costs more the more instances it gets. Set a maximum: how to limit Firebase spending.

Google's page points the same way: it suggests using budget notifications to disable billing on the project. You can build that yourself with a function on the budget's Pub/Sub topic (step-by-step guide), but read what happens when billing stops first: it shuts down every paid service in the project.

Or let FireShield do it. It acts on each budget notification the moment it arrives, can send a Soft Kill webhook so your app degrades itself before billing is cut, and on Pro it watches each service's usage for spikes, so a runaway shows up within the hour instead of on the next cost report.

1. Test in the Local Emulator Suite, with a limit on every query.
2. Know your normal usage per product, and check it after every release.
3. Create a budget, knowing it only sends alerts.
4. Turn on spend caps for AI Logic, App Hosting, Cloud Functions and Extensions.
5. Restrict API keys, turn on App Check, cap function instances.
6. Connect something that acts on the budget without waiting for a human.