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

How to limit Firebase spending on the Blaze plan

October 21, 2026 · 6 min read

There is no project-wide spending limit on Blaze. The six limits you can stack instead, from budget thresholds to max instances, API quotas and an automatic kill switch.

Is there a spending limit on the Blaze plan?

Not for the whole project. On the Blaze plan you pay for what you use, and the budget you set when upgrading is an alert: Firebase says budget alerts "do not cap your usage or charges" (pricing plans). What you can do is stack several limits, each covering part of the risk. Here they are, from cheapest to strongest.

1. Set a budget with sensible thresholds

It won't stop anything, but it's the signal everything else hangs on. Google's defaults are 50%, 90% and 100% of actual spend; Firebase suggests "50% and 100% of Actual as well as 150% of Forecasted" (budget alerts). Remember that the first notification can take several hours to arrive.

2. Turn on spend caps where they exist

Firebase's spend caps (Preview) pause a service for the rest of the month when it reaches its budget. They cover Firebase AI Logic, App Hosting, Cloud Functions for Firebase and Extensions only, and Google notes they are "not 'hard caps'": overages during the reporting delay are still billed.

3. Cap the scaling of your functions

A runaway function costs more the more instances it gets. Set a maximum: Firebase calls it a way "to control your costs" (manage functions). At the limit, extra HTTP requests queue for up to 30 seconds and then get a 429.

import { onRequest } from "firebase-functions/v2/https";

export const api = onRequest({ maxInstances: 10 }, async (req, res) => {
  // ...
});

4. Cap API requests with quotas

Most Google APIs let you set a per-day or per-minute request quota. Google describes these as caps on "requests per day, requests per minute, or requests per minute per user" (capping API usage), and is clear they regulate volume, not money, and take effect with some latency. Useful for AI APIs where one leaked key can generate thousands of requests.

5. Close the doors attackers use

Security rules and App Check keep strangers from reading your database or calling your callable functions with your bill. They're covered in detail in denial of wallet attacks.

6. Act automatically when a threshold is crossed

The only thing that turns a budget into a limit is something that acts on it. You can wire a function to the budget's Pub/Sub topic that disables billing (step-by-step DIY guide), or use FireShield, which does it for you with a gentler step first: a signed webhook that lets your app degrade itself before billing is cut.

Which ones do I need?

Side project: budget + function max instances + an automatic Hard Kill at 100%. Losing a day of uptime beats a surprise bill.
Product with users: all of the above, a Soft Kill at a lower threshold so the app degrades instead of dying, and spike detection on the services that can run away fastest.