Can I put a spending limit on Cloudflare?

Budget alerts vs spend policies: what actually stops the bill

Cloudflare has two completely different systems for tracking your costs, and confusing them will leave you with an unexpected charge on your card.

The first system is budget alerts. You can find these in the dashboard by navigating to Manage Account > Billing > Billable Usage and selecting Create budget alert. A budget alert monitors your account-wide spend across all usage-based products combined using a dollar amount you define. When your cumulative spend crosses that threshold in the current billing period, Cloudflare sends a single email notification to your recipients, and the alert resets at the start of each new billing period. Cloudflare's documentation is explicit about this: budget alerts are informational only. They don't pause traffic, they don't cap usage, and your monthly invoice remains the authoritative source of what you owe.

Cloudflare also provides usage notifications, which monitor an individual product using a raw metric like bytes, requests, or minutes rather than dollars. Like budget alerts, these are just alerts. Neither of them will step in if a script goes haywire at 3 a.m.

The second system is Spend Policies. Spend policies live exclusively in the Cloudflare API under the /accounts/{account_id}/billing/spend-policies endpoint. A spend policy targets a specific product balance in the current billing period using an integer number of US cents (threshold_cents). Crucially, a spend policy supports two distinct actions:

• notification: Sends an email to a bare email address in notification_email. You can have as many notification policies as you want.
• usage_block: Blocks further usage of that product until the end of the billing period once the spend balance reaches the threshold.

If you want a real spending limit, a usage_block spend policy is the only native mechanism Cloudflare provides. For a deeper look at the broader ecosystem, see our guide on which cloud and AI providers let you set a hard spending cap?.

How to create a usage_block spend policy via the API

You cannot build a usage block from the Cloudflare web UI. You have to send a POST request to the billing API.

There are strict rules for how these policies work:

1. Each account can only have one enabled usage_block policy per product. If you try to create a second enabled usage_block for the same product, the API returns an HTTP 409 error.
2. The product_id must be either workers or durable_objects. No other products are supported.
3. The threshold_cents field must be an integer greater than zero (minimum 1, which represents $0.01).
4. The display name must be between 1 and 200 bytes long after surrounding whitespace is trimmed.

Here is a raw curl call that sets a $50 spending block on Workers:

curl -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/billing/spend-policies" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Workers Monthly Hard Cap",
    "product_id": "workers",
    "action": "usage_block",
    "threshold_cents": 5000
  }'

When this policy triggers, Cloudflare cuts off usage for that product across the entire account for the rest of the billing period. If you need to restore service before the cycle resets, you have three options: raise the threshold_cents value above the current balance, disable the policy, or delete it entirely. You can do this by issuing a PUT or DELETE request to /accounts/{account_id}/billing/spend-policies/{policy_id}.

Keep in mind that the balances evaluated by spend policies are asynchronous estimates rather than a synchronous usage read at the edge. Because edge metrics take time to aggregate, a sudden, massive traffic spike can rack up billable usage before the background balance updater flags that the limit has been hit. In the policy's current_state, the status field reports disabled, no_current_period, unavailable, below_limit, or limit_reached. Cloudflare notes that this status reflects threshold evaluation, not proof of an edge cap. Furthermore, seeing no_current_period or unavailable does not imply you have a zero balance or that you're below your limit.

What is covered, what is not, and the R2 problem

Spend policies sound great until you realize how narrow their scope is. Cloudflare spend policies only support two values for product_id: workers and durable_objects. Each product maintains a separate balance and its own distinct policies.

That leaves Cloudflare R2 completely uncovered. R2 has no spend policies, no automated usage blocks, and no way to disable public bucket access when a dollar threshold is crossed.

R2 includes a free tier each month with 10 GB-month of Standard storage, 1 million Class A operations (writes, lists), and 10 million Class B operations (reads). Egress bandwidth to the internet is always free. But once you exhaust the free tier, Standard storage costs $0.015 per GB-month, Class A operations cost $4.50 per million, and Class B operations cost $0.36 per million. If you use Infrequent Access storage, it costs $0.01 per GB-month, $9.00 per million Class A operations, $0.90 per million Class B operations, and $0.01 per GB for data retrieval. If someone discovers an open R2 endpoint or hammering script, R2 will process Class A and Class B operations until your credit card fails.

For more details on monitoring these sudden spikes, read how do I get alerted when Cloudflare usage-based billing jumps?.

Pricing traps and per-request CPU guards

Setting a policy at the billing layer is your backstop, but you should also configure product-level guards so you don't trip that backstop unnecessarily.

On the Workers Paid plan ($5 per month minimum), you receive 10 million requests and 30 million CPU milliseconds per month. Additional requests cost $0.30 per million, and additional CPU time costs $0.02 per million CPU milliseconds. Inbound requests to static assets are free and unlimited, outbound subrequests made from a Worker aren't billed, and calling another Worker via a Service Binding only counts as a single request (billing the initial invocation plus the combined CPU time of both Workers). When Workers Caching is enabled, requests served from cache are billed at the standard request rate, but CPU time is only billed when the Worker actually executes on a cache miss or bypass.

The danger on Workers Paid is CPU duration. On the Standard usage model, the default maximum CPU time is 30 seconds per invocation, which you can raise up to 5 minutes (or 15 minutes for Cron Triggers and Queue Consumers). If an endpoint gets stuck in an expensive computation or heavy processing loop, every single invocation can consume up to 30 seconds of billable CPU time. You can protect yourself by capping the CPU time per request to a tight limit in your configuration so expensive requests fail quickly instead of running up charges. For a deeper breakdown of these tiers, check our guide on how does Cloudflare Workers pricing work?.

Durable Objects have their own set of billing gotchas:

• Compute duration is billed by wall-clock time while running or idle in memory unable to hibernate.
• Calling accept() on a WebSocket inside a Durable Object keeps duration billing running for the entire connection time unless you use the WebSocket Hibernation API.
• Duration billing charges for a full 128 MB of memory per instance, even if multiple instances share an isolate or consume far less.
• Overages round up to the next billable unit before rates apply - 500,000 GB-s of billable compute duration rounds straight up to 1,000,000 GB-s at $12.50 per million GB-s.
• SQLite-backed Durable Objects include 25 billion row reads, 50 million row writes, and 5 GB-month of storage, but key-value backed storage charges for read units ($0.20/M), write units ($1.00/M), delete units ($1.00/M), and storage ($0.20/GB-month).

If you want to understand how attackers exploit these mechanisms, read what is a denial-of-wallet attack, and how do I defend against it?.

Auditing and inspecting your spend policies

Because spend policies run in the background via API, you need visibility into how Cloudflare evaluates them. The billing API provides two dedicated endpoints to inspect what happened:

To see state transitions recorded when Cloudflare evaluates your spend policy against your balance, run:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/billing/spend-policies/$POLICY_ID/audit" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

To see configuration changes across your policies (when a policy was created, updated, enabled, disabled, or deleted), call the activity endpoint:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/billing/spend-policies/activity" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

You can also list all active policies with a GET to /accounts/{account_id}/billing/spend-policies or fetch an individual policy with GET /accounts/{account_id}/billing/spend-policies/{policy_id}.

Automating Cloudflare guardrails with Costbrake

Managing API payloads and watching asynchronous billing estimates manually is tedious. Costbrake monitors spend across Cloudflare and 22 other providers (like AWS, OpenAI, and Vercel) so you don't have to write custom polling scripts.

Costbrake reads your Workers, R2, and Durable Objects usage priced at list rates, replacing them with billed daily dollars about a day later when pay-as-you-go figures settle. It checks usage hourly on the Free plan, every 5 minutes on Pro ($12/month) and Team ($39/month), and drops to 1-minute checks during an active spike. If an hour costs more than 3x your 7-day baseline and at least $5 above normal, you get an immediate spike alert via email, Slack, Discord, webhooks, or PagerDuty.

When things go wrong, Costbrake includes manual, opt-in brakes that an admin confirms in the UI. For Cloudflare, those brakes let you:

• Block Workers or Durable Objects usage with an official Cloudflare spend policy set to $0.01.
• Turn off public workers.dev and preview URLs while keeping custom routes and queues live.
• Turn off the public r2.dev URL on an R2 bucket without touching S3 API access or Worker bindings.
• Detach custom domains and routes, pause queue delivery, pause cron triggers, or cap per-request CPU limits.
• Roll back a Worker to its previous version.

You can link your account by pasting a read-only token scoped to Account Analytics Read and Billing Read, or hand it off to your coding agent via agent setup.