How do I avoid a surprise Firebase bill on the Blaze plan?

Spark vs Blaze: what changes when you add a card

Firebase has two tiers: the no-cost Spark plan and the pay-as-you-go Blaze plan. Spark requires no credit card. If your project hits a no-cost limit on Spark, Firebase shuts that product off for all apps in your project until the month rolls over.

Upgrading to Blaze links a Cloud Billing account. You're also upgraded automatically if you use paid Google Cloud services like Pub/Sub or Cloud Run, or if you use Google Maps APIs in the same project. If you unlink that billing account later, your project downgrades back to Spark immediately. That downgrade cuts off paid Google Cloud tools, stops new deployments of existing or new Cloud Functions, and removes console and API access to any non-default Realtime Database instances or non-default Cloud Storage buckets.

The good news is that Blaze doesn't strip away your free quotas. You still get no-cost project-level allowances across core services, and you only pay for resources you consume beyond those limits (with the exception of Cloud Functions for Firebase). Several products remain completely free on both Spark and Blaze:

• App Check, Crashlytics, and Performance Monitoring
• Cloud Messaging (FCM) and In-App Messaging
• A/B Testing and App Distribution
• Firebase ML (model deployment)
• Authentication (most options; with Identity Platform, no-cost up to 50K monthly active users and 50 SAML/OIDC MAUs)

Even free products can have hard boundaries, such as the 64kB custom logging limit in Crashlytics.

The code mistakes that burn through quotas

Most spike invoices don't come from sudden product popularity. They come from runaway code loops running against infrastructure with auto-scaling enabled.

The first classic trap is an unbounded database query. If a collection grows to several million documents and a client queries it without an explicit limit clause, that single query consumes millions of read operations. On Blaze, Cloud Firestore Standard edition gives you 50K reads a day for free, so an unindexed or unconstrained query can blow through your daily quota in seconds and begin racking up usage fees.

The second culprit is an event loop in Cloud Functions. If a Cloud Function triggers on a document write in Firestore or Realtime Database, and that same function updates the document or fires another function that writes back to it, you get an infinite execution loop. A few hundred invocations quickly become millions of invocations and hundreds of thousands of CPU-seconds.

# Test Cloud Functions, Firestore, and Realtime Database locally
firebase emulators:start

Use the Firebase Local Emulator Suite. It runs local instances of Cloud Functions, Cloud Firestore, Realtime Database, and other services on your machine. Testing locally ensures you don't burn production invocation quotas while debugging triggers.

Alerts-only budgets vs spend cap budgets

Google Cloud Billing provides two types of monthly budgets for Firebase projects: alerts-only budgets and spend cap budgets. You need to know the difference, because one stops spending and the other just sends you mail.

When you upgrade to Blaze in the Firebase console, you're prompted to create an alerts-only budget. You can also configure them later in the Google Cloud console. Alerts-only budgets send emails when your spending hits set percentages of your target number, but they do not stop your services. If a function is spinning in a loop, an alert email lets you know you're spending money, while the loop keeps running.

Spend cap budgets are different: they actually pause the service for the rest of the month once spending reaches 100% of the target amount. However, spend caps have strict restrictions:

• They are limited to a single project and a single eligible service.
• In Firebase, spend caps only apply to Firebase AI Logic, Firebase App Hosting, Cloud Functions for Firebase, and Firebase Extensions.
• The eligible Google Cloud API services are Cloud Run functions (cloudfunctions.googleapis.com, Service ID 29E7-DA93-CA13), Cloud Run (run.googleapis.com, Service ID 152E-C115-5142), Gemini API (generativelanguage.googleapis.com, Service ID AEFD-7695-64FA), and Gemini Enterprise Agent Platform (aiplatform.googleapis.com, Service ID C7E2-9256-1C43).
• Spend caps do not support Cloud Firestore, Realtime Database, or Cloud Storage.

Spend cap budgets send uncustomizable alert emails at 50%, 80%, and 100% of the budget to project owners and billing administrators. To set one up, your account needs the billing.budgets.configureSpendCap permission on the billing account or billing.resourcebudgets.configureSpendCap on the project. For deeper setup steps, read our guide on how Google Cloud spend cap budgets work.

Storage free tiers on default .firebasestorage.app buckets apply only in us-central1, us-west1, and us-east1. Legacy *.appspot.com buckets follow separate daily limits (such as 1 GB/day downloaded).

Watching product dashboards and billing latency

You can monitor project consumption in the Firebase console under Settings > Usage and billing. This dashboard compares your overall usage against your free quotas. You can also view dedicated breakdowns by date range under the individual Usage tabs for Authentication, Realtime Database, Cloud Firestore, Cloud Storage, Cloud Functions, and Hosting.

Pay attention to quota reset windows. Cloud Firestore and Cloud Storage usage quotas are calculated daily, but Cloud Functions usage resets monthly.

Keep latency in mind. While spend caps calculate gross estimated costs using list prices to act quickly, Google Cloud billing report details typically take up to a day to process, and they can sometimes take more than 24 hours to appear. That lag means you cannot rely on billing reports to spot real-time runaway traffic. If you rely on standard budget notifications, see our guide on configuring Google Cloud budget alerts so you aren't blindsided.

Also, spend caps don't stop everything instantly. In-flight requests process to completion, and ongoing persistent resources like storage continue accruing charges. Furthermore, if you lift an enforced spend cap manually, it stays lifted and will not trigger again for the rest of the monthly billing period unless you increase the target spend amount.

Catching spikes early with Costbrake

Because native Google Cloud billing reports run hours behind and spend caps don't cover core databases like Firestore, catching runaway consumption requires monitoring live telemetry.

Costbrake watches what you spend across 23 cloud, AI and SaaS providers, including Google Cloud, AWS, Azure, Cloudflare, Vercel, and OpenAI. Instead of waiting for billing exports, Costbrake monitors Google Cloud by reading BigQuery billing exports alongside live Cloud Monitoring metrics for Cloud Functions, Cloud Run, the Gemini API, and Vertex AI.

When an unexpected loop hits, Costbrake flags it:

• Spike alerts fire if an hour costs more than 3x your 7-day hourly baseline and at least $5 above normal.
• Threshold alerts trigger at 50%, 80%, and 100% of custom budgets, alongside forecast warnings if your 72-hour pace projects an overage by month-end.
• Notifications route to email on all plans, with Slack, Discord, and webhooks on Pro, and PagerDuty on Team.

For services running on Cloud Functions or Cloud Run, Costbrake includes an opt-in, reversible killswitch called a brake. It never fires automatically; an admin confirms the action in the dashboard. When triggered, the brake sets a zero Google spend cap on that service in that project, causing Google to pause new calls. You can learn more on the Costbrake pricing page or configure access via agent setup.