The DDoS Burst Gap: When Protection Reacts Slower Than the Attack

In its Q3 2026 DDoS threat report, Cloudflare recorded 18.2 million network-layer attacks and 14.4 trillion HTTP DDoS requests in a single quarter, about 8,200 attacks per hour. The headline is not the record-breaking floods. It is the shape of the ordinary attack: 96 percent ended within 10 minutes, and 98 percent stayed under 1 gigabit per second. The largest attacks actually fell, while the total count rose 208 percent year over year. The swarm has replaced the giant.

A sub-10-minute, sub-1-Gbps burst is small enough and short enough to raise a fair question about any protection stack: can it react inside the burst, or does the attack end before the defense engages? The answer is rarely a simple yes or no, and it is rarely "you have no protection." It depends on three things a protection product rarely advertises together: the rate-limit window it evaluates over, how it counts, and where the mitigation actually runs.

Why a short burst can slip past a rate-limit rule

A rate-limit rule decides whether to act by counting requests over a window. The length of that window, and the way it counts, decide whether a brief spike is visible at all.

Fastly states the effect plainly in its own documentation: a limit of 100 requests per second measured over a 60-second window "will equally allow 100rps for sixty seconds or 6000rps for one second." A short, high-amplitude spike raises a long-window average far less than a sustained flood, so it can sit under the threshold and never trigger the rule. AWS describes its rate-based rule as a weighted estimate that "gives more importance to more recent requests" and notes it is "not intended for precise request-rate limiting," adding that requests can arrive "at too high a rate for up to several minutes before AWS WAF detects and rate limits them." Azure documents its Front Door rate limit as a fixed window of one or five minutes that resets at the boundary, so a burst that straddles the edge can split across two windows.

None of this is a flaw. These are availability controls doing what they were designed to do, which is to catch sustained abuse. The question for a short burst is simply whether a window built for sustained abuse can see it.

Category 1: edge and cloud WAF rate limiting

These are the knobs most teams configure themselves. The useful distinction is not the brand but whether the product offers a dedicated short-burst detector in addition to a general rate-limit window.

• Coarse single window, no dedicated burst detector. AWS WAF rate-based rules evaluate over a minimum 60-second window. Azure Front Door uses a fixed 1 or 5 minute window. A spike shorter than the window, staying under the per-window count, is below the control. AWS is candid that its automatic application-layer mitigation timing varies and "some DDoS attacks might end before the custom rules are deployed."
• Fine window or adaptive layer. Google Cloud Armor allows windows down to 10 seconds, and its Adaptive Protection uses a machine-learned baseline, though that baseline needs at least one hour to form and then suggests a rule rather than applying one automatically. Cloudflare allows a 10-second minimum window and runs a separate autonomous edge engine that it says mitigates most attacks in about three seconds on average. Fastly allows a 1-second window, which is itself a usable burst control.
• Explicit burst threshold. Some products ship a detector built specifically for the spike. Akamai App and API Protector evaluates hits per second over a two-minute averaging interval and adds a separate burst threshold measured over a 5-second window. Gcore WAAP pairs a global threshold with a burst threshold that fires when traffic reaches five times the previous 2-second interval. Imperva publishes a 3-second time-to-mitigate SLA for Layer 3 and 4 attacks, measured end to end from the first attack packet.

Category 2: always-on inline hardware

Dedicated appliances sit inline, so every packet is already on the mitigation path and there is no window to wait out. Radware DefensePro uses an FPGA mitigation engine and real-time signature generation that its datasheets describe as detecting and protecting in under 18 seconds, with no pre-existing signature required. Check Point DDoS Protector is built on the same DefensePro engine. F5 offers a leaky-bucket or token-bucket rate limiter with a configurable burst multiplier in Distributed Cloud, and a behavioral, stress-based DoS engine with dynamic signatures in BIG-IP AFM. These architectures tend to react fastest to a short burst, at the cost of sizing the box or path for peak traffic.

Category 3: flow-sampled detection with on-demand diversion

Carrier-grade and scrubbing-center models often detect from sampled flow telemetry such as NetFlow, sFlow, or IPFIX, then divert traffic to a scrubber using BGP when an attack is confirmed. NetScout Arbor Sightline works this way and pairs with TMS, which can run in diversion mode or inline. In diversion mode, the time from the start of a burst to active mitigation includes the flow sampling interval, BGP route convergence, and reinjection, which for a sub-10-minute burst can be a meaningful fraction of, or longer than, the attack itself. The same vendor deployed inline reacts far faster. Always-on scrubbing shortens this further: Akamai Prolexic, for example, offers a zero-second mitigation SLA for always-on customers, measured from the alert, while its on-demand path depends on the customer routing traffic and on route propagation. The deployment mode, not the logo, decides.

The pattern: it is rarely "no protection"

Across all three categories, the common finding is not a missing control. It is a control that reacts more slowly than the burst lasts, or a burst detector that exists but is switched off or tuned above where the real traffic sits. Gcore and Akamai burst thresholds ship with defaults that may be far higher than a given site's normal rate. Cloud Armor only suggests a rule after an hour of learning. An un-tuned burst detector protects about as well as an absent one.

This is also why burst readiness matters more for some assets than others. For a payment API, a trading endpoint, a game server, or any real-time interface, a few seconds of unavailability is a direct loss, and the difference between a 2-second burst detector and a 60-second averaging window is the difference between a non-event and an outage. For a brochure website, a coarse window is usually fine.

How we measure this, and an invitation

DDactic scores exactly this gap. Our Open Protection Index reads the protection a given asset actually has, the vendor and the layers it covers, and now factors in burst readiness: how quickly the detected architecture can react inside a short burst, weighted more heavily for burst-sensitive assets like payment and real-time APIs. The point is not to grade a vendor. It is to show, for your own stack, whether a 30-second spike would be caught or averaged away.

Every figure in this article comes from the vendors' own documentation, datasheets, and threat reports. We would genuinely welcome correction. If you work with any of these products and a number here does not match what you see in the field, or a window or SLA has changed, tell us and we will update it with the source. This is meant to be a living, peer-reviewed reference, not a verdict.