On November 13, 2026, Cloudflare opened Spend Management, in beta, to every pay-as-you-go customer. For the first time you can set a spending cap for Workers and for Durable Objects and have the platform stop executing when it is reached. Until now there were only usage notifications and budget alerts, which warn you and keep everything running. Configuration lives under Billing > Spend limits in the dashboard, in the cf CLI and in the billing API, where each rule is called a spend policy.
The detail that weighs on the decision is that the limit is per product and per account. You cannot apply it to a single Worker, a Durable Objects namespace or an environment.
What stops when the cap is reached
For Workers, the limit adds up requests and CPU time after the usage included in the plan. The Workers Paid subscription is excluded, as are KV, R2, Workers AI and every other product. Once the amount is reached, Cloudflare rejects new invocations of every Worker in the account: HTTP requests (visitors get error 1103), Cron Triggers, Queue consumers, Email Workers and calls from other Workers or Durable Objects. Static assets served without running the Worker stay online; routes using run_worker_first can fail.
For Durable Objects, the limit counts requests, duration, SQLite rows read and written, and key-value storage operations. While the block is active, new requests through a stub, SQL queries, storage growth and new setAlarm() calls are refused. Pending alarms are held, and the documentation warns that an alarm scheduled more than seven days ago is deleted while held; the application has to schedule it again afterwards. Some things keep accruing charges: requests already running, messages on WebSockets that are already open, operations in legacy key-value-backed objects, and stored data.
That is why the documentation itself says the limit does not guarantee a maximum invoice. According to the announcement, spend is measured with a delay of up to ten minutes, and propagating the block also takes time.
Who needs to look closely
Anyone running production and tests in the same account. The documentation gives the example: a test Worker can use up the shared limit and take down a production Worker in the same account. The same reasoning applies to anyone hosting several clients or products in one account: one cap becomes everyone's cap.
It also changes little for teams whose costs are dominated by R2, KV or Workers AI, because those charges do not count toward the Workers limit. For inference, Cloudflare points to AI Gateway spend limits, which work per user, model or provider.
The period used is the subscription billing cycle, not the calendar month. If the subscription renews on the 15th, the counter resets on the 15th.
What to do now
Nothing is mandatory: the limit only applies to accounts that configure it. The choice is between risking a high invoice and risking an outage, the same trade between invoice predictability and availability discussed in Fixed CDN pricing still depends on the usage tier.
For an account running a product that earns revenue, the lower-risk path is the email alert without blocking (with Block usage turned off), which notifies at 80% and 100% of the amount and keeps the application running. Blocking makes more sense in a separate account for experiments, previews or agents, where stopping is better than paying.
If you do turn on blocking, a few precautions come straight from the documentation:
- check the spend already accrued in the cycle before saving: a $50 limit on an account already at $60 pauses the product as soon as the rule is evaluated;
- a limit created in the dashboard has no email recipient; you need to add
notification_emailthrough the CLI or the API to be notified; - if you rely on Durable Objects alarms, know which ones could be held for more than seven days and have a way to recreate them;
- to come back online you have to raise the limit above current spend, turn it off or remove it, and the change takes a few minutes to apply.
The record of who changed each limit appears in the dashboard and in the account's Audit Logs, which helps decide who should be allowed to touch it.
What is still unknown
Cloudflare says other products are coming "soon", with no list or date. The gap between measurement and blocking should drop below one minute, according to the announcement, also without a deadline. Budgets per application or per agent task, which would solve the problem of a limit that applies to the whole account, are planned and do not exist yet. There is no date for the end of the beta.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
