Roll out Cloudflare WAF and bot rules without breaking production

Who this is for: platform and security teams turning on Cloudflare WAF, rate limiting, or bot protection for zones that carry real traffic. The method comes from our published migration playbook, and it belongs to the Onboarding stage of the four-stage delivery model.

Why observe first?#

A rule that blocks the wrong request is an outage with a security label on it. Payment callbacks, partner integrations, and monitoring services often look like automation to a rule written against attack traffic. Observing first moves that discovery from a customer complaint to a log review.

Which actions does Cloudflare offer, and which plans have Log?#

Cloudflare recommends Log for validating rules before a more severe action, but custom rules on Free, Pro, and Business support every action except Log. Managed rulesets are less clear: the Cloudflare Managed Ruleset page lists Log as an override action without a plan restriction, while the actions reference calls Log Enterprise-only. Check the action list in your own dashboard.

The WAF rollout runbook: observe, challenge, block#

This is the WAF rollout runbook. Each phase has an exit condition and a rollback. Exit conditions are about evidence, not elapsed time: Cloudflare publishes no observation period, and a monthly billing run will not appear in a three-day window.

Only start phase 3 for rules whose matches you can classify. A rule whose events you cannot explain stays in phase 1 or 2.

How do you review events?#

Cloudflare has two views. Security Analytics shows all traffic, whether or not Cloudflare acted on it, and does not count Log, Skip, or Allow actions as mitigated. Zone-level analytics are included on every plan, with up to 31 days of data on Free, Pro, and Business and up to 90 days on Enterprise; results are sampled by default. Security Events shows requests that any Cloudflare security product acted on or flagged, filterable by action, host, country, ASN, user agent, path, and IP, for up to 31 days on all plans; Free shows sampled logs only.

Review by rule, then by path, then by client. One rule matching many requests from one partner address is an exception candidate; the same rule matching a spread of unrelated addresses on a login path is likely the traffic you meant to catch.

Observing without Log on Free, Pro, and Business#

Do not guess. In Security Analytics, enter the filters the rule would use, read the matching traffic as a population, refine the filters until you recognize every client, then select Create custom security rule to build the rule from them. Give it an action you can tolerate being wrong, such as a Managed Challenge on one path, and watch Security Events.

This is not equivalent to Log: historical filtering shows what traffic looked like, not what the rule will do next week, and a live challenge can reach a real visitor. Two plan limits shape the filters: bot score needs Bot Management on Enterprise, and attack score is unavailable on Free and Pro, with Business limited to the attack score class. Our practice, as in the playbook, is to go live on a low-risk subset first.

How do you write exceptions?#

Two mechanisms exist. Skip rules bypass one or more security features for matching requests, such as passing a trusted API client through rate limiting or exempting a monitoring service from managed rules. They can skip managed rules, rate limiting rules, and Super Bot Fight Mode, but not Bot Fight Mode. Managed ruleset exceptions bypass managed rules under conditions, while overrides change a rule’s action or disable it; Cloudflare states that “Exceptions have priority over overrides.” Ruleset and tag overrides also apply to future rules; rule overrides affect existing rules only.

Cloudflare’s account-takeover guide says to create the skip rule first, so monitoring tools, health checks, and partner integrations are not blocked. Write each exception as narrowly as the evidence allows: path, method, and a stable client attribute such as a partner’s published address range. Record the owner and the reason in the rule description.

What changes for bot rules?#

Start bot rules where the harm is concentrated, such as login and checkout. Cloudflare defines verified bots as bots it has confirmed to be transparent about who they are and what they do. Its AI bot policies, available to all customers, can also block verified bots with matching behavior, and Cloudflare introduced new AI bot defaults for new domains from September 15, 2026, so check the current setting rather than inheriting it. Cloudflare recommends Managed Challenge for most WAF rules, but challenge pages do not work for AJAX or fetch requests: test API and mobile clients before enforcing.

What about rate limiting and detections?#

Rate limiting rules are available on every plan, with 1, 2, 5, and 100 rules on Free, Pro, Business, and Enterprise. Free and Pro count by IP only; the maximum mitigation timeout is 10 seconds on Free, 1 hour on Pro, and 1 day on Business and Enterprise. The parameters page lists block, challenge, and log actions; Log remains Enterprise-only. Start with a generous threshold on one sensitive path and tighten from evidence.

WAF detections such as attack score and leaked credentials detection have no log-only mode: once enabled, they populate fields that rules and analytics use. Treat them as inputs to a rule, then follow the runbook for that rule.

How do you keep the rollout reversible?#

• Keep the rules in Terraform: Cloudflare documents version control and rollback as purposes of its provider, so reverting a rule is a code revert and an apply.
• Give each rule a description with its owner, the date, and the phase.
• Change one rule’s action at a time and review events after each change.
• Name the person who may disable a rule quickly, and rehearse it.