Caps

What caps can and can't stop

The honest boundaries of a SignalFlare hard cap, and what to do about the gaps.

A cap cuts traffic. That covers most of the ways a Cloudflare bill runs away, but not all of them. Know which ones apply to you.

Caps stop

Request floods and crawlers on a Worker route. Remove the route and requests stop reaching the Worker.
Abuse on a specific path. Enable a WAF block or rate-limit rule you prepared, and keep the rest of the site up.
Cron jobs that loop or run too often. Pause the triggers.
Traffic on a forgotten workers.dev URL. Turn it off.
Queue consumers stuck in a retry loop. Pause the queue’s delivery.
Bots hammering the whole zone. Raise the security level to I’m Under Attack.

Storage you already hold. R2, D1 and KV storage bill per GB-month whether or not traffic flows.
Loops that live inside Cloudflare. Durable Object alarms that reschedule themselves, or Workers calling each other through service bindings never pass through a route. A cap on the entry route won’t reach them.
Workers reachable only through a Custom Domain. Custom Domains bypass zone routes. Use a WAF rule on that hostname instead.
Spend between checks. See timing and overshoot.

Add a circuit breaker to loops. Read your budget level from the status API inside the alarm handler or queue consumer, and stop rescheduling at critical or exceeded.
Set CPU limits. Cloudflare lets you cap CPU time per request with limits.cpu_ms in your Wrangler config. It bounds a single runaway request, not the bill, but it helps.
Get a second pair of eyes. A risk review walks through your account for loop-prone paths and sets caps that match how your app is built.