Google Cloud Spend Caps Reach General Availability for a Limited Set of Services; Release Notes Say October 13, Google's Blog Says October 31
Google Cloud spend caps on Cloud Billing Budgets are generally available for four services, with an API and monthly resets; Google's release notes date it October 13 and its blog October 31, and the cited pages differ on which costs trigger a cap.
Editor's Note ·
- Clarification:
- The article says the Google blog post is dated October 31, 2026 on its page while its metadata gives 2026-10-30, without stating the basis. The page's published_time is 2026-10-31T00:00:05+0100 (23:00 UTC on October 30); the page date follows that +01:00 offset and the 2026-10-30 date is UTC. The Cloud Billing release notes state no time zone for their October 13, 2026 entry, and no cited page explains the gap between October 13 and the blog post.
- Clarification:
- The Maps comparison contrasts Google's April 22, 2026 post, which listed Maps among the private-preview services, with the general-availability documentation, which lists four services. Google's July 29, 2026 public-preview post, which the article also cites, already listed four services (Gemini API, Agent Platform, Cloud Run, Cloud Run Functions) and not Maps, so Maps was absent from the supported-services list before general availability.
Overview
Google Cloud has made spend caps on Cloud Billing Budgets generally available, InfoQ reported on November 10, 2026. InfoQ describes a cap as letting customers pause new usage of a service in a project once a monthly budget is reached, without deleting resources, and says enforcement remains limited to the Gemini API, the Gemini Enterprise Agent Platform, Cloud Run and Cloud Run functions.
Google’s own pages date the general availability differently. The Cloud Billing release notes list “Spend cap budgets are now generally available for a limited set of services” under October 13, 2026. The Google Cloud blog post is dated October 31, 2026 on its page (its page metadata gives 2026-10-30) and opens with “Today, we’re announcing that spend caps on Google Cloud Budgets are generally available.” None of the Google pages cited in this article explains the gap, and this article does not reconcile the two dates. InfoQ, for its part, writes that criticism of the narrower scope came “when the preview expanded in October”.
What the general-availability release adds
The Google Cloud blog post, written by Shruthi Nambi, a senior product manager, lists three updates since the preview, which InfoQ also lists as the changes between the July public preview and general availability:
- An API. The blog says Google has “launched the spend caps API, which can be accessed from the existing Cloud Billing Budgets API”, and says teams can “instantly apply a spend cap whenever a developer spins up a new sandbox project”.
- Estimated live costs. According to the blog, “Spend caps for AI services trigger within minutes of usage using estimated, live costs.”
- Automatic monthly resets. The blog says that in the preview a triggered cap stayed in place until someone lifted it in the console, whereas enforced caps now reset and blocked services resume at the beginning of the next month. The manual override remains for teams whose governance requires a manual audit before services resume.
Before general availability, Google announced the feature in stages. A Google Cloud blog post dated April 22, 2026 announced a private preview and said spend caps were “coming soon”. The Cloud Billing release notes list a preview under July 27, 2026, and a Google Cloud blog post dated July 29, 2026 describes it as a public preview.
How a cap behaves, according to Google’s documentation
The spend cap documentation (page marked last updated 2026-11-04 UTC when read on November 10) says a cap is scoped to a single project and a single eligible service, with a monthly budget period starting on the first day of each month. Its table of eligible services lists the Gemini API, the Gemini Enterprise Agent Platform (formerly Vertex AI), Cloud Run and Cloud Run functions, and its FAQ adds: “Additional services will be included in subsequent releases.” Folders, organizations, labels, multi-project or multi-service budgets, reseller accounts and subscription costs such as Gemini Enterprise subscriptions are listed as out of scope.
When a cap is enforced, the documentation says, all new usage of the service in the project is paused, including pay-as-you-go usage and usage covered by committed use discounts. In-flight requests are processed to completion and accrue charges, and persistent resources “(such as compute and storage services)” keep running and keep accruing charges. The Google blog adds that Provisioned Throughput is never halted. Alerts go to billing administrators and project owners; the blog gives the default thresholds as 50%, 80% and 100% of the cap.
Enforcement is not immediate. The documentation says “any cost overages are billed as normal” and advises: “Consider setting your budget slightly below your absolute limit.”
For automation, the Budget API documentation (marked last updated 2026-11-07 UTC) says a budget with a spendCap set is subject to field restrictions: a calendar period of a month, exactly three threshold rules at 0.5, 0.8 and 1.0, and inputState set to CONFIGURED on creation. It also says that while a cap is enforced the budget cannot be edited or deleted until the cap is manually lifted, and that services might take up to one hour to return to normal after a cap is lifted.
Where Google’s pages differ or stay silent
Which costs trigger a cap. The documentation’s list of limitations says cost calculations for spend caps “are based on gross, estimated costs and don’t include savings and credits”. Elsewhere on the same page, the steps for configuring a budget say the estimate applies “For certain services” and that “For the remaining services, we calculate the spend amount using actual costs, inclusive of all savings.” The blog speaks only of “AI services”. None of the Google pages cited here says which of the four eligible services fall into which group, so they do not state whether Cloud Run and Cloud Run functions caps use the faster estimates. InfoQ writes that the estimate that drives enforcement “is calculated at list price and excludes credits and discounts”.
Maps. The April 22 blog post listed Maps among the services in the private preview, and heise online reported on April 27 that the initially supported services included “the Maps APIs”. The general-availability documentation lists four services and does not include Maps, and the general-availability blog post and release notes name no services. That comparison is the Herald’s own; the cited sources do not say why Maps is absent or whether it will be added.
Reaction and comparison
InfoQ offers its own reading of the scope: Compute Engine, Cloud Storage and networking are not among the eligible services, “which means the cap addresses a runaway model or agent loop and not a forgotten GPU instance”. Google’s documentation, quoted above, says caps do not pause persistent compute and storage resources.
InfoQ also reports that a commenter on a Hacker News thread, who had asked Google for the capability a year earlier, called the result “very crude, not granular like the rich IAM system”. It cites developer Simon Willison’s October argument that pay-by-usage services should default to hard caps.
Other clouds’ documentation, read on November 10, describes different designs. AWS’s spend limit page says spend limits are set per project, require a Paid Plan, and that when usage reaches the limit “AWS pauses that project which stops its resources”; the data is preserved, and AWS permanently deletes the project data if no action is taken within 90 days of the pause. Microsoft’s Azure spending limit page says the limit prevents spending over a credit amount and “isn’t available for subscriptions with commitment plans or with pay-as-you-go pricing”.