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

Soft Kill: degrade gracefully before the bill does

October 21, 2026 · 4 min read

Instead of switching the whole project off, let your app turn off its expensive parts when spend crosses a threshold. What to degrade and how to wire it.

The idea

A kill switch that disconnects billing protects your wallet by taking your whole app offline, and Google warns it can leave resources "irretrievably deleted" (details). A Soft Kill is the step before that: when spend crosses a threshold, your own app is told to turn off its expensive parts and keep the rest running.

Users might lose AI features, image processing or live updates for a while. They don't lose the app, and you don't lose your data.

What to degrade, step by step

Pick a few levels and attach each to a budget threshold:

50%: pause batch jobs, heavy exports and anything that can run tomorrow.
80%: switch off the features that cost the most per user (AI calls, video transcoding, real-time listeners), behind a friendly message.
100%: read-only or maintenance mode.
Above that: the Hard Kill, for when degrading wasn't enough.

How to implement it

The usual pattern is a flag your app reads (Remote Config, a Firestore document or an environment value) and a small, authenticated endpoint that flips it. Whatever sends the signal must be verifiable, or anyone could switch your features off.

With FireShield, the signal is a webhook signed with HMAC-SHA256. Your endpoint checks the timestamp and signature, then degrades by level:

const event = JSON.parse(rawBody); // after verifying X-FireShield-Signature
if (event.event === "soft_kill") {
  if (event.thresholdPercent >= 100) await setMode("maintenance");
  else if (event.thresholdPercent >= 80) await setMode("no-ai");
  else await setMode("pause-batch");
}

The full guide, with verification code for Node, Python, Go, Java and PHP, is in Soft Kill webhooks.

Why it beats a single kill switch

You can set it low. Because it doesn't take the app down, a Soft Kill can fire at 50% without anyone dreading it.
It buys time. The reporting delay is still there, but the expensive part of the traffic stops while you investigate.
It works on spikes, not just budgets. On Pro and Enterprise, a usage spike rule (say, Firestore reads at 10 times their normal level) can send the same webhook minutes after the spike starts, with the service that spiked in the payload.