How does FireShield know my bill is spiking?

Google reports each project's spend to FireShield through its budget notifications. The moment a report arrives, FireShield checks it against your thresholds and runs their actions; nobody has to read an email first. How often and how soon Google reports is up to Google.

What does it actually do when a threshold is crossed?

Whatever you set for that threshold. Every budget starts with a Hard Kill at 100% (disconnecting the project's GCP billing account so spend stops), which you can move or remove. On any threshold you can add alerts (email, Slack, Telegram) and, if you want it, a Soft Kill: a signed webhook to your own infrastructure asking it to degrade service.

Do I need to change my application code?

No. You link your project by signing in with Google, which grants FireShield an IAM role on its billing account. Nothing to install. Your code only changes if you choose to use Soft Kills: then you add one endpoint to receive the webhook. FireShield never touches your running services directly.

Can FireShield read my source code or infrastructure secrets?

No. Onboarding is zero-secrets: it uses IAM role grants, not uploaded credentials.

What's the difference between Starter, Pro and Enterprise?

All three protect your projects the same way: unlimited thresholds, email alerts, Soft Kill and Hard Kill. Starter covers one project. Pro covers up to 5 projects and adds Slack and Telegram alerts, per-project spend charts, a spend breakdown by service, and usage spike detection checked every 10 minutes. Enterprise has everything in Pro, with no limit on projects and spike checks every 5 minutes.

Does FireShield work with Firebase projects?

Yes. Firebase runs on Google Cloud, so any Firebase project on the pay-as-you-go Blaze plan is a GCP project FireShield can protect. If you've ever hit a surprise Firebase usage limit or a Blaze plan bill that got out of hand, that's exactly the scenario FireShield exists to stop.

What is usage spike detection?

Google reports spend with a delay of 15 minutes to several hours, so a runaway can grow before any budget alert fires. On Pro and Enterprise, FireShield also reads the usage of each service (Firestore, Cloud Functions, Storage, Realtime Database, Hosting, Gemini) and compares the last hour with the same hour over the last 7 days. When a service jumps past the multiplier you set, say 10 times its normal level, it runs the actions you chose: an alert, a Soft Kill or a Hard Kill. It measures usage, not cost, and you turn it on per project, which grants FireShield read-only access to that project's usage metrics.

← All posts

Guide

Why Firebase budget alerts don't stop your bill

October 21, 2026 · 5 min read

A Firebase or Google Cloud budget only sends alerts, and they arrive hours late. What Google's docs say, and what actually stops the spend.

The short answer

A Firebase or Google Cloud budget is an alert, not a limit. When your spend crosses 50%, 90% or 100% of the amount you set, Google sends an email or a Pub/Sub message, and nothing else happens: your Firestore reads, your functions and your downloads keep running and keep billing. Google says it plainly in the Cloud Billing docs: setting an alerts-only budget "doesn't automatically cap Google Cloud or Google Maps Platform usage or spending."

The Firebase docs repeat it: budget alerts "do not cap your usage or charges", they are alerts "so that you can take action, if needed" (Firebase pricing plans). Someone has to read the alert and do something. That's the gap.

Why the alert arrives late

Even if someone is watching, the alert itself lags behind the spend. Google documents three separate delays:

Cost reporting. "There is a delay between your use of Google Cloud resources, and the usage costs reporting to Cloud Billing" (budgets doc).
Notification cadence. Budget notifications go to Pub/Sub "multiple times per day", not continuously (programmatic notifications).
Daily usage calculation. For Firebase, "Cloud Firestore and Cloud Storage usage are calculated daily" and "Cloud Functions usage is calculated monthly" (avoid surprise bills).

On a brand new budget, Google warns it "may take several hours before receiving the first email or Pub/Sub notification". A function stuck in a loop or a script hammering your database doesn't wait that long.

What about Firebase spend caps?

In 2026 Firebase added spend caps, in Preview. They are a real step forward, with two limits worth knowing:

They cover only Firebase AI Logic, App Hosting, Cloud Functions for Firebase and Extensions. Firestore, Realtime Database and Cloud Storage are not covered, and those are where most read loops and download floods happen.
Google itself says spend caps "are not 'hard caps'": they act on the same delayed cost data, and "any cost overages incurred during this delay will be billed as normal."

Turn them on if you use those products. Just don't read them as a ceiling on the whole project.

What actually stops the spend

Something has to act on the alert without waiting for a human. In practice:

Tell your app to slow down. Turn off expensive features, pause batch jobs or show a maintenance page while you investigate. We call this a Soft Kill.
Disconnect billing as a last resort. With no billing account, Google stops every paid service in the project. It works even if your code is broken, but it has consequences you should read first: what happens when billing stops.
Catch the spike before the cost report. Usage metrics (reads, invocations, bytes downloaded) show up in Cloud Monitoring within minutes, long before the cost does.

You can build the first two yourself with a Pub/Sub-triggered function (see the DIY kill switch), or let FireShield run them for you: it listens to your budget notifications, runs a Soft Kill or a Hard Kill at the thresholds you choose, and on Pro and Enterprise watches each service's usage for spikes.