Cloudflare rate limiting basics

What rate limiting does

Cloudflare rate limiting lets you place a threshold on requests: when a client exceeds the configured count within the configured window, the edge responds with a block (often showing as a 429 status or the Cloudflare "You are being rate limited" 1015 response) and stops further visits from that client for a fixed duration.

The technique protects login forms, search endpoints, checkout, and repels scrapers. It is configurable, so you choose the limit, the pattern, the mitigation, and the duration, unlike a raw edge status-code policy.

HTTP 429 versus the rule

There is an important distinction:

| HTTP 429 | Cloudflare rate limiting |

| 429 means "too many requests" by default | A Cloudflare rule is a configurable management action |

| Defined by the origin application | Triggered by Cloudflare rules, surfaced as 429, 1015, or a challenge |

| Same code from any server | The Cloudflare block page calls it "rate limited" |

Cloudflare rate limiting is therefore not identical to the HTTP 429 contract. It uses a 429 response (or a dedicated block page showing error 1015) when a rule fires, and also offers options like "Managed Challenge" instead. Your own origin can still return 429 independently of Cloudflare.

Build a rate limiting rule

1. Open Security > WAF > Rate limiting rules in the dashboard, then Create rule.
2. Define the match. Limit to the path you want to protect:

(and
  (http.request.uri.path eq "/wp-login.php")
  (ip.src.country eq "ALL"))

1. Set the rate. A login page commonly uses something like:

| Parameter | Example value |

| Requests | 20 |

| Period | 60 seconds |

| Mitigation | Block |

| Mitigation duration | 300 seconds |

1. Test the rule body. A login page with real users rarely exceeds 20 requests per minute; rate that high lets a small burst settle without challenging humans. Use 10 requests per 120 seconds for strict scraping protection.
2. Save and verify. Exclude your own office IP from the rule, then watch the rule fire and release from analytics.

Design notes

• Match the narrowest feasible fragment. Do not rate-limit every path when the target is known: /wp-login.php or /api/v3/orders is enough.
• Group by the right identifier. ip.src is the default, but behind CGNAT or shared office IPs, group instead on http.request.uri.path plus a client-selected key.
• Use "Managed Challenge" for a visitor-friendly rate limit: normal users who trip the cap get a quick HTML challenge and pass, bots merely receive the block. For login endpoints specifically, blocking is usually safer, because a challenge is less effective than a hard stop against automated credential stuffing.
• Watch the total rule set. Cloudflare applies rules in order, and there is a finite free-plan count. Track your profile under Security > Settings to see how many rules you have left.

Frontend principles

Good rate limiting is the fallback, not the goal. Cloudflare's own guidance favours designing the frontend so it does not need a high request budget in the first place: bundle assets, cache static resources, avoid scripts loading dozens of requests per page, and respect long TTLs for content that changes rarely. A page that makes 200 requests per load on a 100-request-per-minute rule will trip the rule on its own, with nobody attacking. Keep the origin lean and the frontend honest, and the rate limit stays reserved for actual abuse rather than normal behaviour.

429 and 1015 in your logs

When you see repeated 429s in Cloudflare analytics, a rule fired. Check:

• Which rule (the rule ID in the analytics or the event in Security events).
• Which client and which path (the request and the cf-ray ID).
• Whether the rule fired on a shared IP or on a crawler (often the case on wp-login).

A 429 on the origin itself, on the other hand, is the origin application returning the code, not a Cloudflare rule.

Prevention

• Set up a separate rule for the worst attack (login, checkout) independent of the general per-IP tide.
• Watch geolocation rules that could block a legit market; combine a country match with known network patterns.
• Test after every WAF template update, because the bundled templates run under rule order.
• Keep the rule list reviewed monthly: Cloudflare changes match criteria across products, so a stale rule can silently stop matching.