On This Page8 sections
Key Takeaways
- Cloudflare Workers can now automatically block new invocations when spending reaches a limit you choose. Cloudflare launched Spend Management in beta for pay-as-you-go customers on November 13, 2026, with support for Workers and Durable Objects.
- Every Worker in an account shares the Workers limit. Request and CPU charges count after included usage. The subscription fee and charges from products such as R2 and Workers KV are separate.
- A site can remain partly online after a pause. Cloudflare can still serve static files directly while requests that need Worker code fail. Scheduled tasks and queue consumers are also affected.
- The final invoice can exceed the threshold. Cloudflare measures usage and distributes the blocking decision across its network. Requests can run while that decision takes effect.
What changed for Cloudflare Workers?
Previously, a budget alert could tell a developer that a deployment was getting expensive. Someone still had to see the notification, find the workload, and intervene. With Block usage enabled, Cloudflare can take the first action automatically and reject new Worker invocations across the account. Teams that need uninterrupted service can keep using alerts alone. Cloudflare describes both options in its Spend Management announcement.
The distinction matters during a bad deployment. An image-processing Worker, for example, can start using substantially more CPU per request while traffic looks perfectly normal. Because the spending limit tracks both requests and CPU charges, it can respond to a cost increase that a request-volume alert would miss.
What does a Workers spending limit cover?
| Control | What counts | What happens at the threshold |
|---|---|---|
| Workers spending limit | Request and CPU overages across all Workers in the account | New Worker invocations are blocked once enforcement takes effect |
| Durable Objects spending limit | Object requests, duration, SQLite rows read or written, and key-value operations | Supported operations are blocked across the account’s Durable Object namespaces |
| Product email alert | Recorded spend for Workers or Durable Objects | The selected recipient receives a notification while usage continues |
| Account budget alert | Account-wide usage-based spend | Recipients receive a broader billing notification while services continue |
A Worker’s dependencies can have their own bills. Consider an endpoint that accepts an image, stores it in R2, and calls an AI model. Its Workers limit covers the request and the CPU used by the Worker. R2 storage and model inference fall outside that limit. For inference requests routed through AI Gateway, Cloudflare offers separate budgets scoped to a user, model, or provider. The billing guide explains how these controls fit together.
How to enable a Cloudflare Workers spending limit
- Select the Cloudflare account that owns the Workers. Open Billing and look for Spend Management or Spend limits.
- Check the Workers charges already recorded for the current subscription period. A policy created mid-cycle includes that earlier usage.
- Open the Workers controls, enter the spending threshold, and enable Block usage. To receive warnings while traffic continues, configure an alert and leave blocking off.
- Save the change and verify the policy state. If notifications matter, confirm that a recipient is configured. Set a separate Durable Objects policy if the application needs one.
Check current spend before saving. If it already exceeds the new threshold, Cloudflare can pause Workers as soon as it evaluates the policy. The billing period follows the subscription renewal date, which may fall in the middle of a calendar month. The dashboard setup guide covers both details.
To review the account’s configured policies from a terminal, sign in with the Cloudflare CLI, select the intended account, and run:
cf billing spend-policies listThis read-only command is useful during a handover or incident when someone needs to check which products have blocking policies. The CLI reference also documents policy creation, updates, and change history.
What actually stops when the limit is reached?
A storefront illustrates the effect. Its homepage, stylesheet, and product photos might all be served as static assets. A customer can still open the page and browse the catalog, then encounter an error when Add to cart calls a Worker. A homepage uptime check would report success throughout.
| Request or task | Behavior after Workers enforcement |
|---|---|
| Static asset served directly | The asset remains available |
| HTTP request that requires Worker code | Cloudflare rejects the invocation and the visitor can receive error 1103 |
Asset request routed through run_worker_first | The request can fail because Worker execution comes first |
| Cron Trigger or queue consumer | New invocations are blocked, interrupting scheduled or background work |
| Call from another Worker or a Durable Object | The call can fail when its destination Worker is blocked |
Cloudflare does not bill requests it rejects under the spending limit as Worker invocations. Error 1103 can also have other causes, so check the product’s billing status before diagnosing an outage. The Workers spending limits documentation lists the affected invocation types.
How to choose between alerts and automatic blocking
Start with the cost of an interruption. For a disposable preview environment, pausing execution may be preferable to letting a faulty job run overnight. For an account that also handles checkout or authentication, the same decision affects paying customers. A staging Worker and a production Worker in that account cannot have independent Workers spending limits.
Choose an alert threshold that buys response time. Subtract the alert amount from the blocking limit, then divide that difference by the fastest plausible spend per minute. The result is the approximate time available to investigate. Metering and notification delays shorten that window, so a warning set just below the limit may arrive too late for manual intervention.
Monitor a dynamic route as well as the homepage. A read-only request that exercises an important Worker can detect a partial outage without placing an order or modifying customer data. For background processing, the equivalent check is the elapsed time since the last successful job.
How to restore service after a spending pause
First, identify what consumed the budget. If a release made each request more expensive, roll it back before raising the limit. Otherwise, reopening traffic can restart the same spending pattern.
To resume service in the current period, raise the limit above recorded spend, turn it off, or remove it. Allow a few minutes for the change to propagate. Turning a policy off and back on preserves the period’s accumulated spend. If the policy stays in place, the block expires at the next subscription billing period and the configured limit carries forward.
Applications using Durable Objects need one additional check. A Worker can resume while the object it calls remains blocked by its own policy. Pending object alarms can also be delayed, and Cloudflare deletes held alarms that were scheduled more than seven days ago. After restoring both products, verify a real application request and reconcile any overdue jobs using the Durable Objects recovery rules.
Conclusion
Cloudflare Workers spending limits give developers a choice that billing alerts alone could never provide: let traffic continue, or automatically pause execution when eligible charges reach a chosen threshold. Before switching on Block usage, review the current billing period and identify the most important route that would stop. Use that route to decide whether the account should alert, block, or do both.
Continue Reading
More articles connected to the same themes, protocols, and tools.
Referenced Tools
Browse entries that are adjacent to the topics covered in this article.
