Rate Limiting Gets a Data-Driven Setup and a Softer Touch

Rate limiting rules remain a core defense against volumetric attacks, credential stuffing, scraping, and API abuse. But two long-standing pain points have nagged at users: figuring out the right request threshold and dealing with the bluntness of a temporary ban. Cloudflare has addressed both for Enterprise customers with the release of Rate Limit Analysis in Security Analytics and a new throttle behavior for rate limiting rules.

Rate Limit Analysis: Stop Guessing at Thresholds

Security Analytics already helps you build custom rules by filtering HTTP traffic on signals like bot scores or mitigated requests. But setting a rate limit rule has always required a separate judgment call: what maximum request rate should you enforce? That number depends on your application's normal traffic patterns, peak hours, and endpoint specifics—data that wasn't easily visible in the analytics view before.

The new Rate Limit Analysis tab inside Security Analytics closes that gap. It focuses specifically on request-rate questions rather than raw traffic volume.

From Top Stats to Per-Client Rates

Standard Security Analytics filters let you slice traffic by top statistics—for example, seeing requests from the most active ASNs or hitting your most popular paths. That works for many rule-creation scenarios, but rate limiting needs a finer view: how many requests each individual client sends within a time window.

The Rate Limit Analysis tab displays request-rate data for traffic matching your chosen filters and time period. You pick a rate interval (one minute, five minutes, or one hour) and the client identifier to use—IP address, JA3 fingerprint, or both combined for better accuracy. The chart then shows a distribution of request rates for the top 50 unique clients observed in that window, ordered from highest to lowest rate.

A slider lets you preview the impact of different thresholds: how many clients would a given rule catch and rate limit? You can visually separate high-rate abusers from the long tail of typical users, which guides you toward a sensible cutoff for your specific endpoint and traffic profile.

Building a Rule with the Data in Front of You

Using the analysis to create a rule takes only a few steps. Let's walk through a typical scenario: setting up a rate limit on a /login endpoint based on IP with a logging action.

  1. Define the scope and rate. In the HTTP requests tab, choose a time window. For a normal traffic baseline, pick a period outside peak hours; to study offending traffic, pick a window when an attack occurred. Filter for your endpoint (e.g., /login) and optionally narrow to human traffic with the bot score quick filter. In the Rate Limit Analysis tab, select your client characteristic—JA3, IP, or both—and the rate interval. JA3 is available to Bot Management customers. Move the threshold line on the chart to see how many clients would be affected at different rates.
  2. Refine the view. You can filter out IPs or ASNs you recognize to get a cleaner picture of end-user traffic. A good rule of thumb is to place the threshold just before the long tail of normal users begins—this blocks only the highest-rate clients.
  3. Validate the rate. Repeat the analysis using a time period with a known attack or traffic spike. Your chosen threshold should catch the outliers during the attack while allowing normal traffic to pass during quiet periods. Check sampled logs to confirm your filters and client fingerprints look right.
  4. Create the rule. Clicking "Create rate limit rule" opens the WAF rate limiting tab with your filters pre-populated.
  5. Choose the action and behavior. Pick whether to log, challenge, or block requests above the threshold. Logging first is a common practice to validate the threshold before switching to a stricter action. Every action supports two behaviors: fixed action or throttle.

Throttle: Selective Drops Instead of an All-Out Block

Up to now, rate limiting rules used a single behavior: fixed action. Exceed the threshold, say 20 requests per minute from IP 192.0.2.23, and every request from that IP gets blocked (or logged) for a set timeout, such as 10 minutes.

The problem with a fixed penalty is its severity. Consider a corporate network behind a NAT: one device tripping the threshold blocks every device sharing that IP, collateral damage that can easily take down legitimate traffic.

Throttling takes a different approach. Instead of enforcing a pause after the threshold is crossed, it selectively drops or acts on individual requests to keep a client's average rate under the limit. It behaves like a leaky bucket (minus the queuing component). With a throttle rule of 20 requests per minute for a client, each incoming request triggers a check against the average request rate over the last 60 seconds. If the average is below 20, the request passes. If the average is already at the limit, the rule acts on the request—block, log, or challenge—and the next request gets its own fresh check, leaving room for legitimate traffic as time passes.

Throttle works with all three rule actions. One caveat applies to challenge actions: Cloudflare recommends sticking with the fixed action behavior when challenging. With a fixed action challenge, once a client exceeds the threshold, all requests from that client are challenged until they pass one; legitimate users clear the challenge and continue until the threshold is breached again. Throttle behavior is available on Enterprise rate limiting plans.

The new analytics view and throttle behavior are live in the dashboard. Enterprise users can test the workflow and submit feedback through the button on the Analytics page or via their account team.