A safe Cloudflare bot exception is a custom rule with the Skip action, scoped to the exact host, path, method and published source range. It skips only the Super Bot Fight Mode phase, and it has an owner, an expiry and a rollback step. Never skip on user agent or a header, and never skip all API traffic.
Two kinds of traffic need this most: uptime monitors that hit a health path every minute, and third-party webhooks that arrive from a vendor's servers. Both are automated, both are legitimate, and both look like bots to an edge that cannot read your intent. This post walks through one worked example of each, then covers the tests and lifecycle that keep an exception from becoming a permanent hole.
Short answer: scope the skip to host, path, method and source range
A Cloudflare bot exception is a custom rule with the Skip action, and it is only as safe as its expression. Match four things together: the hostname, the exact path, the HTTP method, and a source address range the sender publishes. Drop any one and the rule widens.
Skip options are independent. The dashboard lets you skip the remaining custom rules, specific phases such as All Super Bot Fight Mode rules, rate limiting rules or managed rules, and specific products (Cloudflare Docs). Pick the single phase you need. Select everything and a surgical exception becomes a blanket bypass. That failure mode is the reason this post exists.
Turn on the Log matching requests option so every skipped request shows up in Security Analytics. You can't audit an exception you can't see.
Where an exception sits: custom rules run before Super Bot Fight Mode, and Bot Fight Mode cannot be skipped
Custom rules run before Super Bot Fight Mode, and Super Bot Fight Mode rules run after WAF custom rules in the request evaluation pipeline (Cloudflare Docs). That ordering is why a skip rule works. Your rule matches first and tells the later phase to stand down for that request.
There is a hard limit. Bot Fight Mode, the free tier feature, cannot be bypassed or skipped with WAF custom rules or Page Rules, and JavaScript Detections are not available as a configurable setting in Bot Fight Mode (Cloudflare Docs). If your zone runs Bot Fight Mode and your monitor is being challenged, no custom rule fixes it. You must move to a plan that includes Super Bot Fight Mode, which Cloudflare lists under Pro, Business and Enterprise.
Check your plan before you write a rule that can't take effect. For a comparison of the tiers, see Cloudflare's own docs for each mode, and for how score thresholds behave on other routes, read Cloudflare bot score: set thresholds by route.
Worked example 1: a fixed-egress uptime monitor on one health path
The easy case is a monitor that publishes fixed egress addresses and probes one URL. Suppose it checks GET https://api.example.com/healthz from 203.0.113.10 and 203.0.113.11. The expression is:
(http.host eq "api.example.com"
and http.request.uri.path eq "/healthz"
and http.request.method eq "GET"
and ip.src in {203.0.113.10 203.0.113.11})
Set the action to Skip, choose only All Super Bot Fight Mode rules, and enable logging. Leave rate limiting and managed rules unticked. Your WAF rules and rate limits keep protecting /healthz from everyone, including the monitor.
Prefer a maintained list over pasted addresses. If the monitoring vendor publishes its ranges, store them in a Cloudflare IP list and reference the list in the rule. A range change then becomes a list edit instead of a rule rewrite.
Make the health endpoint boring. It should return a static body and touch no database. A narrow exception on a path that does real work is still a risk, and if you need the monitor to exercise a full API flow, that is a different decision with a different owner. When an API call returns HTML where JSON should be, the cause is usually a challenge, and Cloudflare API challenge: diagnose HTML instead of JSON covers that triage.
Worked example 2: a webhook receiver and why origin signatures cannot authorize the skip
Webhook senders usually sign each delivery, and your application verifies an HMAC before trusting it. That check is correct and you should keep it. It does not authenticate a skip rule.
The reason is ordering. The edge decides whether to challenge or block before the request reaches your origin. The origin-side signature check runs after that decision, so it can't tell Cloudflare to let the request through. A skip rule has to match on what the edge can see at that moment: host, path, method, and source address. Don't match on User-Agent or on an arbitrary header such as X-Signature or X-Webhook-Source. Any client can send those strings, so a rule built on them is an open door with a label on it.
Suppose a payment provider posts to POST https://hooks.example.com/stripe-events from ranges it publishes:
(http.host eq "hooks.example.com"
and http.request.uri.path eq "/stripe-events"
and http.request.method eq "POST"
and ip.src in $payment_provider_ranges)
Skip All Super Bot Fight Mode rules only. Two layers now do separate jobs. The edge rule admits traffic from the right network to the right path. The origin verifies the signature and rejects forged or replayed bodies. If the vendor publishes no source ranges, you have no safe edge identifier. The honest options are a dedicated path with tighter rate limits or a different delivery mechanism. A looser rule is not one of them.
Negative tests, delivery IDs, retries and idempotency
Test what the rule must not allow, not just what it must. Run these from a machine outside the allowed range, and record the results in the change ticket:
- Same path and method, wrong source address: still challenged or blocked.
- Right source address, different path such as /admin or /healthz-debug: still evaluated normally.
- Right source and path, wrong method (a POST to the health path): still evaluated normally.
- Right everything with a spoofed User-Agent claiming to be the monitor: no change in outcome, because the rule never reads it.
Then confirm the positive case with real traffic. For the monitor, find its actual check in the Security Analytics Events tab and verify it shows as skipped. For webhooks, trigger a real delivery from the vendor's test console and match its delivery ID against your logs and the skip log entry.
Plan for retries. Senders retry on any non-2xx response, so a transient challenge produces duplicates later. Store delivery IDs and make the handler idempotent: process a given ID once, return 200 for repeats. A rule outage then can't corrupt state, because replayed events land safely.
Exception lifecycle: owner, expiry, range rotation and rollback
Every exception needs four fields in the rule description or your change system: an owner, a reason, an expiry date, and a rollback step. A rule with no owner outlives the vendor relationship that justified it.
Owner. One named person or team, not a shared mailbox. They answer when the rule matches something unexpected.
Expiry. Set a review date. Ninety days is a sensible default. Treat the date as a deadline to renew with evidence or delete. Renewal means re-running the negative tests.
Range rotation. Vendors change egress addresses. Subscribe to their change notices, keep ranges in an IP list, and diff the published list against yours on a schedule. A stale range fails in one of two ways: the monitor starts alerting falsely, or an address once leased to the vendor now belongs to someone else and still gets the skip.
Rollback. Know in advance how to disable the rule in one action, and what happens next. For a monitor, rollback costs you false alerts. For a webhook, it costs you queued retries, which idempotency absorbs.
If you also run the same check across other stacks, the approach to monitor identity carries over. See Nginx bot protection: rate limits, real IPs and safe rollout and AWS bot protection: WAF Bot Control levels and safe deployment.
When static exceptions stop being enough, and how Centinel Analytica fits beside your CDN
Static exceptions work when the sender has a fixed, published identity. They strain when the traffic you need to admit is a moving target: a partner without published ranges, a crawler you want to allow selectively, or a flood of requests claiming to be an approved bot. Anyone can type GPTBot into a User-Agent, and Centinel Analytica's published research found that 84% of requests claiming to be GPTBot on a typical news site were fake.
Centinel Analytica provides bot and AI crawler protection that tells real visitors from scrapers and applies allow, challenge or block policy through your existing CDN or edge. The exception handles the sender you can identify by network. Centinel Analytica handles the traffic you can't pin down with an address list.
If you want to see how your own traffic looks, explore Centinel Analytica and compare it against the exceptions you maintain today.
FAQ: not being blocked by Cloudflare, enabling bot management, and the free tier
The questions below cover the checks people run most often when Cloudflare catches a legitimate automated client. Short answers sit in the FAQ at the end of the post.
Keep every exception narrow, owned and temporary
A good Cloudflare bot exception is the smallest rule that works: one host, one path, one method, one published range, one skipped phase, with an owner and an expiry. Run the negative tests before you ship it and rerun them on renewal. For the traffic a static rule can't name, see what is hitting your edge beside the monitors and webhooks you already trust.
Frequently asked questions
How to not be blocked by Cloudflare?
If you own the site, add a custom rule with the Skip action scoped to your host, path, method and the sender's published source range, skipping only the Super Bot Fight Mode phase. Do not match on User-Agent or headers. Free Bot Fight Mode cannot be skipped by custom rules. Centinel Analytica can add policy beside your CDN for the traffic ranges cannot cover.
How to enable Cloudflare bot management?
Bot Fight Mode is a free toggle, and Super Bot Fight Mode is included with Pro, Business and Enterprise plans. Enable either in the Security settings for your zone, then review Security Analytics events before tightening actions. Add Skip rules for known automation first. Centinel Analytica works alongside Cloudflare if you need protection beyond what your plan provides.
Is Cloudflare bot management free?
Part of it is. Bot Fight Mode is a free product that helps detect and mitigate bot traffic. Super Bot Fight Mode is included in Pro, Business and Enterprise subscriptions. Free Bot Fight Mode cannot be bypassed with WAF custom rules or Page Rules, which matters if a monitor or webhook sender is being challenged.
Can an origin signature check authorize a Cloudflare skip rule?
No. Custom rules and bot features are evaluated at Cloudflare's edge before a request reaches the origin. An application-verified signature therefore cannot affect an earlier edge skip decision, though an edge rule can match request attributes available at the edge. Scope the skip to host, path, method and source range, keep signature validation at the origin as a second layer, and make handlers idempotent.