How much does one hour of bots cost on Cloudflare Workers?

Santiago Gascón · September 2026 · 7 min read · every price below is a list price checked this week, sources at the end

Cloudflare Workers Paid has no spending limit. Not a soft one, not a hidden one — none. Budget Alerts arrived this year, and the docs say exactly what they are:

"Budget alerts are informational only. They do not pause or cap usage."Cloudflare Billing docs, Budget alerts, updated May 2026

When someone on Hacker News wrote that they would "never use them without prepayment or spending limit options," Cloudflare's CTO answered:

"It is in the works. The billing team has been sprinting to fix a lot of debt in this area. I don't have a date."dknecht, Hacker News, "Cloudflare Flagship" thread, June 2026

So I did the thing I kept putting off before moving my own store's Workers to the paid plan: I ran the numbers. This is what one hour of bots actually costs, where the bill gets scary, and what the native caps on Vercel, Supabase and Netlify do when they trip — which is not what you'd hope. There's a calculator at the end.

The honest number: Workers themselves are cheap to abuse

Take a bot storm of 5,000 requests per second against a Worker route. That's 18 million requests an hour.

That's the number people quote when they say the fear is overblown — "1 million requests to a Worker is only $0.30 and there's no bandwidth charge" is a real HN comment, and it's correct. It's also why the famous $23,000 Vercel bill — a DDoS billed at bandwidth rates — can't happen on Workers. The request meter is not where the risk lives.

Where the slope gets steep: what the Worker touches

The bill gets interesting when every one of those 18 million requests does one more thing. Same hour, same 5,000 req/s, list prices as of September 2026:

A signup form that writes a row per submission, an upload endpoint that writes to R2, a counter that touches KV on every page view — those are ordinary designs, and each turns the $7 hour into a $20–90 hour with the same zero-cap billing underneath. Call a Workers AI model per request and the per-request cost goes up by orders of magnitude; the shape is the same, the slope is steeper. And none of this counts the third-party APIs your Worker calls — OpenAI, Anthropic, Twilio, Resend — which bill on their own meters. A leaked key has the same shape as a bot storm: a wall, not a ramp.

None of it is dramatic per request. All of it is uncapped.

This isn’t hypothetical. In January 2026 two ordinary bugs — a missing dedup check and an insert without ON CONFLICT — wrote about 4.8 billion rows to D1 on a $5-a-month account, and the bill came to $4,868. Cloudflare waived it, after 18 days of escalation across four support channels. The author’s writeup is worth reading; he built an open-source breaker afterwards.

"Just stay on the Free plan" is the other failure mode

The Free plan has a hard quota: 100,000 requests per day. At 5,000 req/s it's gone in 20 seconds, and for the rest of the UTC day your Worker returns errors. Your bill is $0. So is your uptime. That is a spending cap — the bluntest possible one — and it's the reason people upgrade in the first place. D1 got the same treatment on September 1, 2026: once a Free account passes its daily row limits (5 million reads, 100,000 writes), every D1 query fails until midnight UTC.

What the native caps actually do (September 2026)

I checked every platform's current docs before writing this, because it changed this month.

Two things stand out. Vercel's Flat Rate CDN is a real improvement: CDN requests and Fast Data Transfer become a capacity tier with spike protection, so the "$23,000 of bandwidth" story is largely off the table for teams that have it on. But it does not cover Fluid compute invocations ($0.60/M), Fast Origin Transfer ($0.06–0.43/GB), ISR, image optimization or Blob operations — the meters a bot storm on a function route actually spins. Our same hour against a Vercel function route is about $65 before CPU and memory (18M × $0.60 + 900 GB × $0.06), and the thing protecting you is Spend Management, which pauses the whole team.

The second thing: every cap that exists is binary. Either nothing happens, or everything stops. There is no "this one route is on fire, slow it down."

What a breaker should do instead

This is the design I'm building, and I'm publishing it because I'd rather be corrected now than after launch:

1. Watch the meters that bill, not the ones that are convenient. On Cloudflare that's the GraphQL analytics for Worker invocations, KV, R2 operations and D1, polled every 60 seconds with a read-only analytics token. On Vercel it's the spend webhook plus usage-anomaly alerts plus a daily billing reconciliation, because there is no real-time usage API. On Supabase, the API counters.
2. Compare to your own baseline. A launch looks like a ramp over hours; a bot storm looks like a wall in minutes. The rule is "3× your 7-day median for 10 minutes", not "$50".
3. Escalate before pausing. Warn (email, SMS, Slack) → Throttle (a rate-limit rule on that path, or security_level: under_attack on that one host, never the whole zone) → Pause (detach the Worker route; on Vercel, promote the last static deployment, then pause that one project). One project, never the account.
4. Undo in one click, with a post-mortem that says what was seen, what was done, and what it would have cost.
5. Warn-only for the first seven days of any rule, so you see what it would have done before it can do it.
6. Never run the breaker on usage-billed infrastructure. A bill watchdog that can get its own surprise bill is a joke.

When Cloudflare ships its spending limit, I expect it to look like everyone else's: account-wide, minutes of lag, blunt. If a native cap ever makes this redundant, I'll say so here.