Cloudflare Rate Limiting: A Practical Setup Guide

Cloudflare rate limiting is one of the most effective Cloudflare traffic control tools you have for protecting an origin from abuse, credential stuffing, and scraping, and one of the easiest to misconfigure into an outage. Set the threshold too tight and you throttle real customers during a product launch. Forget that your own integrations poll an endpoint every few seconds and you block them alongside the bots. This guide covers how Cloudflare rate limiting actually works, how to build a rule correctly, and the threshold decisions that separate a rule that protects from one that generates a support queue.

How Cloudflare Rate Limiting Works

A Cloudflare rate limiting rule counts requests matching a defined expression over a rolling time window, and fires an action when the count exceeds your threshold. The rule has four essential parts: a match expression that decides which requests count, a characteristic that decides what to count them by, a threshold expressed as requests per period, and an action that fires when the threshold is crossed. Get those four right and everything else is detail.

The mechanic that trips people up is the counter itself. Two facts about it matter more than anything in the docs. First, counters are scoped per data center rather than globally, and there can be a delay of up to a few seconds between detecting a request and updating the rate counter, which means excess requests can still reach your origin before Cloudflare enforces the action. Rate limiting is a surge control, not a precise per-request gate. If you’re expecting it to admit exactly N requests and block the N-plus-first, you’ll be surprised, and that surprise is the source of most “my rule isn’t working” tickets. Second, each characteristic maintains its own independent counter, which becomes a strategic lever we’ll use later.

Types of Rate Limiting Rules in Cloudflare

Cloudflare has two generations of this product, and knowing which you’re in matters. The current version is rate limiting rules built into the WAF’s Ruleset Engine, managed as one of the security rule types in the dashboard. The older standalone product still exists in some accounts, but Cloudflare is migrating everyone to the newer Advanced Rate Limiting system, so if you’re still on the legacy version, plan the move. Everything in this guide refers to the current WAF-integrated rules.

Capability is gated by plan, and the gradient is steep. Rate limiting has been available on the Free plan since October 2022, but the Free tier gives you basic path-based rules and little more. Pro and Business progressively unlock challenge actions, custom response bodies, and finer control. The full feature set, including account-level rate limiting rulesets deployed across multiple zones and separate counting expressions, sits at Enterprise, which requires application security on the contract. Before you design a rule, know which tier you’re on, because half of “why can’t I do X” is a plan boundary, not a bug.

Step-by-Step: Setting Up a Cloudflare Rate Limiting Rule

In the dashboard, rate limiting rules live under Security, in the WAF section. Create a rule and you’ll configure four things in sequence.

Define Your Matching Criteria

The match expression decides which requests the rule even looks at. Scope it tightly, because a rule that matches too much counts traffic it has no business counting. Combine conditions with and/or logic to target exactly the surface you’re protecting: URI path equals /api/login, HTTP method equals POST, a specific header present or absent. The single most common setup error is scoping a login rule to the whole hostname instead of the login path, which then counts every page view toward a threshold meant for authentication attempts. Match the endpoint, the method, and where relevant the header or cookie that identifies the traffic you actually care about.

Choose Your Counting Dimension

The characteristic is what Cloudflare counts by, and it’s the decision that most determines whether your rule is fair. Counting by IP is the default and the bluntest option. It works until it doesn’t: counting purely by IP punishes users sharing an address behind corporate NAT or a mobile carrier, which is why Cloudflare offers an IP-with-NAT-support option and can identify unique visitors using session cookies. For authenticated flows, count by a session token or a request field like a username rather than IP, so one user on a shared connection doesn’t trip a limit that a hundred users are collectively filling. Pick the characteristic that isolates the abuser without sweeping up their neighbors.

Set Your Threshold and Period

The threshold is requests per period, and both halves need a real number, not a guess. Cloudflare offers a fixed set of period values, from 10 seconds up to a full day. Don’t set either from intuition. Pull your actual traffic first, look at how many requests a legitimate client makes to this specific path in this window, and set the limit above that with deliberate headroom. The next section covers the method in detail, because this is the number everyone gets wrong, and getting it wrong in either direction, too loose to matter or too tight to tolerate, is the whole failure space of rate limiting.

Select the Mitigation Action

The available actions are Block, Managed Challenge, Non-Interactive (JS) Challenge, Interactive Challenge, and Log. Match the action to the endpoint’s sensitivity. Block is right when you’re certain the traffic is abuse and the endpoint isn’t conversion-sensitive. Managed Challenge is the workhorse for anything where a burst might be a real user having a bad day, a login, a signup, because a human solves it and a bot usually doesn’t. Reserve JS and Interactive challenges for narrower cases; they’re heavier on user experience. And Log is not a lesser action, it’s your test harness: run every new rule in Log first, watch what it would have caught against real traffic for at least a week, then promote it to a blocking or challenging action once the evidence is in.

One plan-specific detail that surprises people: on Free, Pro, and Business plans you cannot set a duration when using a challenge action, so the rule always throttles, resetting a visitor’s counter to zero once they pass the challenge; only Enterprise can configure a fixed mitigation duration for challenge actions. “Throttle” here is a duration behavior, not a separate action, which is worth knowing before you go looking for a throttle option that isn’t there.

Common Cloudflare Rate Limiting Mistakes

Five errors account for most misbehaving rules. The first is setting thresholds without baselining normal traffic, which is guessing, and guessing produces limits that are simultaneously too tight for peaks and too loose for attacks. The second is applying limits to paths that serve legitimate high-volume traffic, health checks, status endpoints, API polling, where the “abuse” the rule catches is your own infrastructure doing its job.

The third is IP-only counting on traffic that shares IPs, so a single corporate office or mobile carrier gateway trips a per-IP limit that no individual user came close to. The fourth is leaving a rule in Log mode indefinitely: Log is where a rule starts, not where it retires, and a rule that has been “testing” for three months is protecting nothing. The fifth is forgetting to exclude your own internal services and monitoring from public rules, then wondering why your uptime checks started failing. Each of these is a scoping or baselining discipline, not a Cloudflare limitation, which means each is preventable before the rule goes live.

Threshold Strategy: How to Set Limits That Work

This is the part the reference docs skip, and it’s the part that actually matters. A threshold is a hypothesis about what legitimate traffic looks like, so derive it from data, not from a round number that feels safe.

The method: measure your normal request rate to the path in question, per counting dimension, at the 95th percentile, so you capture real peak behavior without chasing outliers. Set your initial limit at roughly two to three times that P95 value, giving legitimate bursts headroom while still catching volumetric abuse that runs an order of magnitude higher. Deploy in Log, review what the rule would have blocked over a week that includes a genuine traffic peak, adjust the number against what you learn, and only then switch to enforcement. This loop, baseline, log, review, enforce, is the entire discipline, and skipping it is why most rules are wrong.

For endpoints where a single limit is too crude, tier your rules. Cloudflare’s own guidance uses a tiered pattern on login: a first rule allows a few attempts per minute before a Managed Challenge, a second permits a moderate number over ten minutes, and a third blocks a persistent client for a day.The tiering lets a forgetful human through the first gate while escalating on anyone who keeps hammering. And remember the independent-counter property: rate-limiting a login endpoint by IP and by username at the same time creates two counters, where the IP counter catches one address testing many usernames and the username counter catches one username attacked from many addresses. You usually want both.

Concrete starting points for common consumer flows, to adapt against your own baseline:

Endpoint	Count by	Threshold	Action
Login	IP (NAT-aware)	~5 per 10 min	Managed Challenge
Login	Username	~10 per hour	Block
Password reset	Account	~3 per hour	Block
Signup	IP	~3 per hour	Managed Challenge
OTP request	Phone number	~3 per 5 min	Block
Public API	Session or key	2–3x measured P95	Managed Challenge
Scraping-prone path	IP	2–3x measured P95	Block

These are informed defaults, not universal truths. A B2B app with bursty Monday-morning logins needs looser numbers; an internal admin tool with five users can run far tighter. The table is a place to start measuring from, not a configuration to paste in blind.

From Manual Config to AI-Guided Rule Management with LELOPS

Building one rule correctly is manageable. The friction shows up at scale: keeping Cloudflare rate limiting consistent across zones and environments, confirming that a rule you wrote actually matches the intent you had, and answering the question every operator eventually asks, “the rule is live, so why is this traffic still getting through?” That last one is rarely a simple answer, because it could be the per-data-center counter, a matching expression that’s narrower than you think, a characteristic counting the wrong dimension, or a plan limitation on the action you chose.

This is where LELOPS ADVISE earns its place. It understands your Cloudflare configuration, so instead of reverse-engineering why a rule isn’t triggering, you can ask, and get an answer grounded in your live setup rather than in the general documentation. It explains why a rule is or isn’t firing against your actual traffic, and helps you translate the mitigation logic you want into the correct rule syntax without the guesswork that turns a fifteen-minute change into an afternoon. The rule set stops being something only its author understands and becomes something the whole team can interrogate and safely modify.

Not sure if your rate limiting rules are actually working? LELOPS ADVISE understands your Cloudflare configuration and tells you exactly what to change: lelops.ai/product/advise.

FAQ