← All docs
How usage spike detection works
Last updated: October 2026
What it measures
- Usage, not cost. FireShield reads each monitored service's usage from Google Cloud Monitoring: document reads, invocations, data downloaded, tokens and so on.
- It catches what budgets miss: Google reports spend with a delay of 15 minutes to several hours, while usage metrics arrive within minutes.
- It is part of the Pro plan (checked every 10 minutes) and the Enterprise plan (checked every 5 minutes).
- Services you can monitor: Cloud Firestore (document reads, writes and deletes), Cloud Functions (invocations), Cloud Functions and Cloud Run (compute time), Cloud Storage (operations and data downloaded), Realtime Database (data downloaded), SQL Connect (operations), Cloud SQL (bytes sent and transactions), Hosting (data transfer), Vertex AI and Firebase AI Logic (tokens).
When a spike fires
- Normal is the average hour over the last 7 days. An hour with no usage counts as zero, so there is no learning period.
- A rule fires when the last 60 minutes reach the multiplier you set (for example ×10 normal) and are above normal by at least the minimum increase you set.
- The minimum increase is optional. It stops a big multiplier from firing when normal usage is tiny: if normal is 3 an hour, ×10 is only 30.
- A service with no usage all week that suddenly gets traffic counts as a spike from zero, as long as it passes the minimum increase.
- Once a rule fires, it doesn't fire again for that service until usage drops below half the multiplier. A spike that lasts for hours sends one alert, not one per check.
Setting it up
- Open a project in the dashboard and turn on usage spike detection. Google asks you to let FireShield read the project's usage: it gets the read-only Monitoring Viewer role on that project and nothing more.
- Choose a service to monitor. Each monitored service has one rule: its multiplier, its minimum increase and its actions.
- Each monitored service shows the last 7 days of hourly usage, with normal as a dashed line, and its latest spikes beside the chart.
- Turning detection off stops the checks for that project.
What happens when it fires
- The rule's actions run: an email, a Slack or Telegram message, a Soft Kill webhook, or a Hard Kill that disconnects the project's billing.
- A Soft Kill sent by a spike carries the service, the last hour's usage and the normal level, so your code can tell it apart from a budget alert. See Soft Kill webhooks · integration guide.
- A Hard Kill stops everything the project runs. See What is a Hard Kill.
Good to know
- It sees usage, not money: a rule can't tell a cheap spike from an expensive one. Set each service's multiplier with that in mind.
- Cloud Monitoring data arrives a few minutes late, so the newest minutes of a spike show up at the following check.
- It complements your budget, it doesn't replace it. Keep budget thresholds on every project: they are what measures money.
