One service answers only a few requests and still costs more than expected. Another handles many short calls cheaply. Anyone who limits only the number of requests is therefore not automatically measuring what later appears on the infrastructure bill. Cost control and load control act at different points.
On 12 October 2026, Google announced the general availability of Budget spend caps for Cloud Run. Once set up, a spend cap can pause the affected workloads. This is a relevant infrastructure change. But it only becomes understandable once you distinguish between a budget alert, a spend cap and a limit on individual requests.
Three questions, three different limits
A request limit answers questions such as: how many calls may a particular client send within a given period? A limit on concurrent work asks: how much may run in parallel? A cost limit, on the other hand, looks at the priced resource consumption within its scope. These quantities are related, but they are not interchangeable.
Our fictional service has two tasks. One returns a short status response. The other processes a lengthy document. Both start with exactly one request but require different amounts of work. Even if both users are allowed the same number of calls, it does not follow that they place the same load on the infrastructure. A single counter conceals the different significance of its entries.
A budget alert is not yet a stop
The official billing documentation distinguishes alert-only budgets from spend caps. The caps described use estimated gross costs; savings and credits are not included. The scope is a single project and a supported service, and the period is monthly. An operator should make a point of reading these conditions before configuring anything.
Enforcement is not instantaneous either. Google points out that overruns caused by delays are still charged. An amount entered is therefore not a mathematical promise that the final bill will stop exactly there. The new feature offers a technical intervention, not a substitute for understanding how it is billed.
For Cloud Run, the product documentation describes specific effects: services can no longer serve requests and return errors in the 5xx range; other resource types have their own consequences. A cost stop is therefore also an availability decision. This consequence belongs in the planning, not only in the incident report.
A dry run shows which rule applies when
You don’t need to stop a running service to understand the model. Sketch three independent counters: calls per client, work running at the same time and estimated costs in the period under consideration. Assign a response to each. The first rule rejects further calls from a client, the second limits parallelism, and the third can pause an entire defined scope of service.
Client limit: Who may send requests, and how often?
Concurrency limit: How much work runs at the same time?
Spend cap: When is the service in question paused?
Then play through two invented cases: many short requests and a few demanding ones. Enter only qualitative differences, not made-up euro amounts. The exercise shows which rule even sees each case. It is a thought model, not a measured load or cost test.
The operator’s infrastructure is not the customer’s allowance
KENJTEC uses Cloud Run for platform services; this can be traced in the project’s infrastructure and deployment sources. It does not follow that the new Google feature has been activated automatically. Nor does it give every KENJTEC customer account an individually adjustable infrastructure cap. An operator project and a customer subscription are different billing boundaries.
In practice, the important question is therefore: what usage is a limit meant to protect, and what work would also be stopped when it is triggered? A sensible plan describes warning, intervention and resumption together. Only then can you judge how a spend cap fits with request limits and your own availability requirements.
Sources and status
Research and documentation as of 25 October 2026. Cloud Run release notes — October 12, 2026 · Billing settings for services — Budget spend caps · Manage spend cap budgets.

