- On November 13 Cloudflare launched hard spending caps in beta for pay-as-you-go customers, starting with Workers and Durable Objects.
- Once the cap is reached, new invocations are rejected. Spend is measured with a delay of up to 10 minutes.
On November 13 Cloudflare released hard spending caps in beta. You set an amount, and once spending passes it the service stops accepting new invocations by itself. It starts with Workers and Durable Objects for all customers billed on usage, and more products are due to follow soon. It answers the nightmare of anyone running an app or an AI agent in the cloud: a bill that keeps climbing overnight while you sleep.
A warning is not a brake
Until now Cloudflare’s paid plans had usage notifications and budget alerts. The company admits in the announcement that this does not solve the problem, because “informing is not the same as controlling.” An alert arrives by email, and the money keeps flowing until someone reads it and reacts.
The new feature is a hard cap. It applies to pay-as-you-go billing, where you pay for actual usage, and to two services: Workers, which run your code on Cloudflare’s servers, and Durable Objects, which hold application state. Cloudflare says more than 10 million developers now build on its platform, and spending caps have long been one of the most requested features.
Setting it up step by step
- In the dashboard, go to Manage Account, then Billing and Spend limits.
- Pick a product, enter the upper amount and an email address for notifications.
- Add one or more warning thresholds below the cap, so you hear early that something is growing.
- You can set the same cap from the terminal with
cf billing spend-policies createor through the API. In the announcement’s example,threshold_cents: 10000means 100 dollars andaction: usage_blocktells Cloudflare to block usage.
The dashboard shows current-period costs for each product, and an audit log records who changed a limit and when, and when a cap was hit.
What stops and what keeps running
Once the cap is reached, new invocations of paid code are rejected. In Workers, scheduled jobs and queue consumers pause too, but the site’s static files keep being served. To resume you can raise the cap above the spend so far, disable the policy, or wait for the next billing cycle. Watch out for one trap: the cycle starts on the day your subscription began, so a subscription started on October 10 runs until November 10, not to the end of the calendar month.
Why the cap arrives with a delay
The engine that turns usage into money does not sit in the path of every request, because that would slow the whole network. Usage is first grouped into one-minute and then five-minute batches, priced, and the block decision is then spread to servers around the world. Cloudflare calls this near real time, under 10 minutes, and wants to get it below a minute.
In practice, costs can keep rising for a few minutes after you pass the amount. My advice: set the cap a bit below the figure you truly do not want to exceed. Second point: the cap switches off the whole product on the account, not a single app. If your main site runs on the same account, the block stops it too, so in my view it is worth splitting experiments and production into separate accounts.
Next up: budgets for AI agents
Cloudflare writes openly about AI agents that get stuck in loops and generate thousands of dollars in costs. AI Gateway already lets you give a budget for model requests per user or per model. The company wants budgets to also cover the compute, databases and storage a task uses. I show how to work out the cost of a single agent task in Task cost in tokens, and I collect price comparisons in the Model & API pricing hub.