Caps
Hard caps
How caps work, the write token and its scopes, dry runs, arming, what happens at 100%, and restoring.
Paid Cloudflare plans have no spending limit. A SignalFlare cap gives you one: when a budget’s estimated spend reaches 100%, the actions you armed run against Cloudflare’s API and cut the traffic that is costing you money. They stay in place until you restore them.
Caps can be armed on production and on accounts you mark as staging. There is no limit on how large or small a cap can be. See pricing.
Actions
| Action | Risk | What it does | Restore puts back |
|---|---|---|---|
| Remove a Worker route | High | Deletes one zone route, so requests on that pattern stop reaching the Worker. | The route, with the same pattern and script |
| Reroute a Worker route | Medium | Points one zone route at a fallback Worker, such as a static maintenance page. | The original script on that route |
| Enable a WAF rule | Medium | Switches on a rule you created in advance, such as a block or rate-limit rule for an expensive path. | The rule exactly as captured, disabled again |
| Raise the zone security level | Medium | Sets the zone to I’m Under Attack (or High), so every visitor gets a challenge. | The previous security level |
| Repoint a DNS record | High | Changes one A, AAAA or CNAME record’s content or proxied flag. Never touches MX, TXT or other types. | The captured content, proxied flag and TTL |
| Pause cron triggers | Low | Clears a Worker’s cron schedules. | The exact schedules |
| Turn off workers.dev | Low | Disables a script’s *.workers.dev URL. | The previous workers.dev setting |
| Pause queue delivery | Medium | Stops a Queue delivering messages to its consumers. | Delivery resumed |
| Call your webhook | Medium | POSTs a signed cap.fired event to your HTTPS endpoint. See integrations. | A cap.restored event; your endpoint undoes its change |
The dashboard shows each action’s risk, a plain-language warning (what it breaks and how to undo it) and the scopes it needs before you create or arm it. Cap recipes walks through each one.
You can attach several actions to one budget. Most teams cut the expensive path (an API route, a crawler-facing URL, a looping cron) rather than the whole site. Several actions on one budget form a playbook: each can fire at its own percent of the budget, wait for a grace period, or wait for another action.
The write token
Create a second Cloudflare token with only the scopes your actions need, limited to the zones and account you protect:
| Action | Permission |
|---|---|
| Remove or reroute a Worker route | Zone · Workers Routes · Edit |
| Enable a WAF rule | Zone · Zone WAF · Edit |
| Raise the zone security level | Zone · Zone Settings · Edit |
| Repoint a DNS record | Zone · DNS · Edit |
| Pause cron triggers, turn off workers.dev | Account · Workers Scripts · Edit |
| Pause queue delivery | Account · Queues · Edit |
| Call your webhook | None: no write token needed |
Paste it under Hard caps → Write token. It’s encrypted with AES-256-GCM like the read-only token, kept in a separate table, never logged, and only decrypted when a cap runs, a dry run is tested, or you restore. Only organization owners and admins can add or remove it.
Dry run, test, arm
- Create the action. It is born as a dry run.
- Test it. We make the read calls and show the exact changes we would make, plus Cloudflare’s responses. A wrong scope or a missing route shows up here, not at 3am.
- Arm it by typing the confirmation shown, e.g.
ARM search-route. Only owners and admins can arm. - Drill it. A fire drill runs the action live right now and restores it automatically after 1 to 60 minutes, so you know it works before a real breach.
You can disarm at any time. Every create, arm, disarm, run, trip, defuse and restore is written to the audit log with who did it.
Playbooks: degrade in stages
Denying service is the last step, not the first. Each action has three settings that let a budget degrade before it cuts:
| Setting | Default | What it does |
|---|---|---|
| Fires at | 100% | The percent of the budget at which this action runs. Put a low-risk action at 80% and the route cut at 100%. |
| Defuse delay | 0 (immediately) | A grace period of up to 24 hours. When the tier is reached, every channel is alerted and the action is scheduled. An owner or admin can Defuse it from the dashboard before it fires. Disarming also defuses. |
| After | none | Another action that must have run live first. Chain actions into an if-this-then-that sequence. |
A typical playbook for a Worker that is costing too much:
- 80%: pause its cron triggers. Low risk, nobody notices.
- 90%: set the zone to I’m Under Attack, with a 30-minute defuse delay. Bots get a challenge; a human can defuse if the spike is a launch, not a loop.
- 100%: remove the Worker route. The hard cap.
Each step runs once per month per arming, with the same dry run, test, arm and restore as any cap. A defused action stays defused for the rest of the month unless you re-arm it.
Tripping a cap by hand
Press Trip now on any action and type TRIP <action name>. The action runs live immediately, is logged as a manual trip, and restores with the same one-click Restore. Use it when you already know what is burning and do not want to wait for the next check.
What happens at a tier
On the poll where a budget’s estimated spend reaches an action’s tier (100% unless you changed it):
- Each armed action at or below that percent runs once for the month, or is scheduled if it has a defuse delay.
- Cloudflare’s raw responses are stored with the execution.
- Your channels get a “cap ran” alert listing what changed, or a “cap scheduled” alert with the time it fires.
- If a call fails, for example Cloudflare is briefly unavailable, it is retried on the next polls, up to three attempts.
If your plan no longer includes live caps on an account, armed actions run as dry runs instead and tell you what they would have done.
Restoring
Open Hard caps → Executions and press Restore. We put back exactly what we changed, record Cloudflare’s responses, and notify your channels. A cut that has not been restored blocks that action from being re-armed or tripped, so nothing fires twice on top of itself.
Timing and overshoot
Caps act on estimated spend, checked every 5 minutes, from analytics that lag a little. Expect up to one check interval plus that lag of spend past the cap before it runs. If that margin matters, set the budget a little lower than the number you can’t exceed. Read what caps can and can’t stop before relying on one.