Spend controls have been at the top of the list of most requested features from developers building on our developer platform for quite some time now. With more than 10 million developers now building on Cloudflare, this matters more than ever. Although we’ve had usage notifications and budget alerts available to paid plans for a while, this doesn’t solve the problem completely; informing is not the same as controlling.
You can now set spending thresholds and choose to have Cloudflare pause activity when those limits are reached, thus avoiding unexpected bills from unplanned usage. Today, we're introducing Spend Management in Beta, for any pay-as-you-go (PayGo) customer, starting with Workers and Durable Objects. Use Spend Management alongside AI Gateway spend limits to manage compute and AI inference costs across your application.
AI Gateway already supports per-user and per-model budgets for Workers AI and other AI providers, applied to requests routed through your gateway. How it works You can start using Spend Management using the dashboard, cf CLI , or REST API . In the dashboard , head over to Manage Account > Billing > Spend limits and enable the products for which you want to control spending.
When you enable controls on a product, you can define a spending limit, specify a recipient email for notifications, and set one or more alert thresholds. If you configure a recipient email, Cloudflare will send notifications when the evaluated spend reaches one of the thresholds or your spending limit. When the limit is reached, a blocking policy is enforced and your product is paused automatically.
If you go to the dashboard , you can see the current billing cycle costs for each supported product in near real time (under 10 minutes), and manage your settings and thresholds from there. The overview panel tells you which products have thresholds and limits configured. In this example, you can see that Workers triggered two alerts before hitting the hard limit.
Note that the billing cycle starts when the paid subscription begins, not when you deploy a Worker or create a spending cap; a subscription starting October 10 generally has a cycle of October 10-November 10 — not a calendar month. The dashboard also shows an audit log, so you can see who changed a limit and when, or when a cap was reached. As with most Cloudflare services, Spend Management is also an API that you can use programmatically; the documentation can be found in our Developer Documentation .
Here’s an example, but using the API: curl --fail-with-body --request POST \ "https://api. cloudflare. com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/billing/spend-policies" \ --header "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \ --header "Content-Type: application/json" \ --data '{ "name": "Workers spending cap", "product_id": "workers", "enabled": true, "threshold_cents": 10000, "action": "usage_block", "notification_email": "me@example.
com" }' And, of course, you can use cf, the CLI for the entire Cloudflare API : cf billing spend-policies list cf billing spend-policies create cf billing spend-policies get cf billing spend-policies update cf billing spend-policies delete cf billing spend-policies audit list cf billing spend-policies activity list cf billing spend-policies create --body '{ "name": "Workers spending cap", "product_id": "workers", "enabled": true, "threshold_cents": 10000, "action": "usage_block", "notification_email": "me@example.
com" }' Once a cap is enforced, new invocations of that product are rejected. Note that we only pause customer-code invocations that incur costs — in Workers, for example, Cron Triggers and Queue consumer invocations are paused, but static assets continue to be served. To resume service, you can: Raise the limit above the current cycle’s accumulated spend.
Disable or delete the blocking policy. Wait until the next billing cycle, when the existing block expires. That’s it.
You can start using Spend Management for Workers and Durable Objects today, and other products will follow soon. Read on to learn how we built the system, and what’s going to happen next. How we built Spend Management As easy and straightforward as it seems on the surface, building a system like this at Cloudflare scale was no small feat.
From an invocation anywhere on our distributed network to a blocking decision that we need to apply globally, building Spend Management required working with multiple teams, changing code in existing systems, and creating new systems from scratch. Let’s start by looking at the bird's-eye view of a capped billable event: Now let's dig deeper. Collecting and aggregating close to the source Each invocation produces usage measurements: requests, CPU time, execution duration, or storage operations, depending on the product.
But transporting and processing this volume of raw data all the way from the sources down to the rating engine would not scale or be efficient. So what we do is we collect and aggregate the measurements as close to the source as possible using a two-stage metering pipeline that combines events into usage aggregates, so the engine sees accumulated usage rather than having to process all the events one by one.
Let's look at a diagram. The first stage reduces raw-event volume close to parsing down to one-minute windows. Each metering parser converts raw events into usage measurements, then combines matching measurements into typically one-minute buckets.
Still, several records can describe the same account and time window. In the second stage, a separate service merges those first-stage partial aggregates using the same grouping rules, but over typically five-minute windows, and further reduces the volume before downstream processing by the Usage Engine. Here we also archive the consolidated aggregates; this gives us a durable dataset for later analytics and reconciliation.
Originally published at blog.cloudflare.com
