If your DDoS protection depends on someone or something noticing an attack and then redirecting traffic to a scrubbing service, the window you are defending against has mostly closed. According to Cloudflare’s Q3 2026 DDoS Threat Report, published 2026-10-29, 96% of the network-layer attacks it mitigated in July through September ended in under 10 minutes, and 98% stayed under 1 Gbps (Cloudflare, Q3 2026). The count rose 208% year over year to 18.2 million attacks in one quarter (Cloudflare). Before going further, one caveat belongs at the top: every duration and volume figure in this article comes from a single vendor’s telemetry, covering only attacks Cloudflare’s own network mitigated, on a CDN-shaped traffic mix (Cloudflare says, per the same report, its network protects more than 20% of the web). Cloudflare also bundles always-on unmetered protection into the services it sells, so its framing that detection speed is the binding constraint doubles as product positioning. Treat these figures as vendor telemetry until NETSCOUT or Akamai publish a comparable quarterly duration distribution. What follows pairs the numbers with independent academic measurements of mitigation engagement latency and states explicitly where the argument crosses from evidence into inference.
The practical consequence is a change in what you are buying. When almost every attack finishes inside ten minutes, the scarce resource in most defensive designs is not bandwidth headroom. It is the time between an attack starting and mitigation actually engaging. Architectures differ on that latency by orders of magnitude, and the difference now decides outcomes.
The distribution that decides the architecture
Cloudflare’s report, the 26th edition of the series produced by its Cloudforce One threat intelligence team, returns that series to its quarterly cadence after the combined H1 2026 volume, and puts the quarter’s activity in stark terms. The company says it autonomously mitigated 18.2 million network-layer attacks and 14.4 trillion HTTP DDoS requests in Q3 2026, which works out to roughly 8,226 network-layer attacks per hour, or one every 0.44 seconds (Cloudflare, 2026-10-29).
Two percentages matter more than the topline count:
- 96% of mitigated network-layer attacks ended in under 10 minutes (Cloudflare, Q3 2026).
- 98% stayed under 1 Gbps (Cloudflare), which the report notes is still “more than enough to overwhelm a server or website.”
Cloudflare attributes the pattern to the economics of DDoS-for-hire. In its words, “Short-burst, mid-range, high-count attacks — the operational signature of DDoS-for-hire “booter” services, accelerated this quarter.” Booter customers rent short, cheap attacks; frequency is what the business model produces.
The vendor’s own operational claim goes further and is worth quoting because it is the detection-latency thesis stated by the party that profits from it:
“Autonomy is the point: our systems detect and mitigate attacks without human intervention. And they need to, because as this quarter’s distributions make clear, most attacks end long before a human analyst could see the alert, and the largest attacks still regularly exceed 1 Tbps at a cadence measured in hundreds per quarter.”
Take the first half as a hypothesis to test against independent data, not as settled fact. The second half, the terabit tail, is a counterweight the same report supplies, and it matters for the buying decision later.
Three designs, three engagement latencies
The architectures operators actually choose between differ less in peak capacity than in how mitigation gets engaged:
Always-on in-line scrubbing. Traffic permanently routes through a CDN or scrubbing network that inspects and filters continuously. Engagement latency is effectively zero because there is nothing to engage; detection and mitigation run in-line. Cloudflare says every service on its network gets free, unmetered, always-on protection across 330+ cities backed by 500 Tbps of capacity, which is precisely the model its report argues for.
On-demand BGP divert. Traffic normally flows directly to your origin. When detection fires, whether by threshold, tooling, or a human confirming an alert, you announce a BGP change that reroutes traffic through a scrubbing provider, which returns clean traffic via tunnel. The engagement latency is detection time plus BGP propagation plus session re-establishment, and it is measured in minutes under good conditions.
Origin-side filtering. The host or edge device drops attack traffic itself, increasingly with in-kernel eBPF/XDP programs. Engagement is autonomous and immediate, but capacity is bounded by the link and the host; this only works for attacks the link can physically receive.
The arithmetic that follows is simple. If 96% of attacks end inside ten minutes, per Cloudflare’s Q3 numbers, any pipeline whose engagement latency consumes a large share of those ten minutes fails to protect against the first incident of almost every attack it will ever see. The divert does not just arrive late; it arrives after the event it was purchased to stop. That is the inference. It is supported by the duration distribution, but it is not itself a measured result, and the next section shows where it holds and where it does not.
What independent measurements show
The strongest independent evidence on engagement latency comes from an IXP measurement study of roughly 170,000 amplification attacks at a large internet exchange. The researchers measured the delay from attack start to mitigation deployment, and their paper reports that “70% of blackholing rules were installed prior to when we first detect the DDoS attack,” with an average delay of 1.16 minutes for the blackholing. The delay stayed under 10 minutes for 98.7% of deployments and exceeded 4 minutes in 4.2% of them (arXiv:2103.04443); only 19 cases took more than 30 minutes, and the highest delay was 5 hours for an 8-hour long attack.
Two lessons sit in those numbers. First, even a well-automated network-side response, among the fastest such responses measured, operates in the same minutes-wide band as an attack distribution whose median sits under ten minutes. A 1.16-minute average is excellent, and it still means a deployment made after detection, rather than one installed beforehand, leaves the opening minute or more of an attack unfiltered. Second, the tail of that distribution is bad: 4.2% of deployments took over four minutes (arXiv:2103.04443), and a divert-based design with human confirmation in the loop will sit toward that tail, not the average.
The same study cuts against the pure detection-speed story in an important way. The 70% of blackhole rules installed before detection shows what mature automation achieves (arXiv:2103.04443), so “on-demand is structurally too slow” overclaims for operators who have automated their triggers. And blackholing was used in only 3% of the attacks observed (arXiv:2103.04443), so it cannot stand in for in-the-wild mitigation behavior generally. Treat the 1.16-minute figure as a best-case benchmark for automated network response, not a typical divert SLA. If you are evaluating an on-demand provider, their contractual detection-to-mitigation time is the number to demand, and it is a number this article cannot supply.
On the supply side, a study that purchased attacks from booter services directly confirms the swarm’s shape. The researchers configured the two VIP attacks they purchased to last five minutes; that tier advertised 80–100 Gbps (arXiv:1909.07455), but the attacks delivered measured peaks of about 20 Gbps (NTP) and 10 Gbps (memcached), roughly 25% of the advertised rate. Non-VIP attacks averaged about 1,440 Mbps (arXiv:1909.07455). Two implications: five minutes was the buyers’ chosen duration, not a booter product spec, but it sits inside Cloudflare’s sub-10-minute band as a consistency check; and advertised booter capacity overstates delivered volume, so sizing defenses against a booter’s marketing page would overspend.
Finally, routing-plane responses are structurally mismatched to short bursts. The authors of BGPeek-a-Boo, a BGP-based traceback design, state that “individual attacks might be too short for BGP-based traceback,” and their own system runs at roughly 6 BGP advertisements per hour and needs about 4 days to converge. Traceback is not mitigation, but the point generalizes: anything that depends on BGP-plane convergence is operating on a timescale the sub-10-minute swarm has already left behind.
Five minutes is long enough to matter
A natural misreading of the duration data is that short attacks are tolerable attacks. The evidence says otherwise, twice over.
First, 1 Gbps is small only relative to backbone capacities. Cloudflare’s own report notes 98% of attacks stayed under 1 Gbps (Cloudflare, Q3 2026) while being “more than enough to overwhelm a server or website,” and that is the typical unprotected origin: a single server or a small uplink, not a carrier-scale port.
Second, brief unavailability can have outsized consequences for protocols with consensus or coordination steps. A 2025 study of Tor’s directory protocol demonstrated, in a controlled environment, that a five-minute DDoS against a majority of Tor’s nine directory authorities can fail the protocol. The authors price that disruption at “as little as $53.28 per month” (arXiv:2509.10755) to “disrupt the protocol and to effectively bring down the entire Tor network.” That result is protocol-specific and comes from an abstract-level account, so do not read it as a claim about your web application. Read it as the existence proof: a five-minute window, repeatedly purchasable at trivial cost, can break systems whose recovery takes far longer than the attack. Anything with leader election, quorum, or a slow cold start shares the shape of that risk.
The tail that still buys bandwidth
If the article ended here, the recommendation would be wrong. Cloudflare’s own report supplies the counter-evidence, and it is substantial.
Hyper-volumetric attacks exceeding 1 Tbps still numbered 251 in Q3 2026, down from 805 in Q2 (Cloudflare), a decline coinciding with early-2026 law enforcement action that dismantled four of the largest IoT DDoS botnets: Aisuru, KimWolf, JackSkid, and Mossad. Even reduced, that is roughly two to three terabit-class events per day somewhere on one vendor’s network. And duration risk has not vanished either: the quarter’s longest sustained Mirai attack ran 49.7 hours between August 19 and 21, and Mirai-classified mitigation accounted for 46.5% of all mitigated network-layer bytes, peaking at 57.23 PB in August (Cloudflare).
The IXP data sharpens the same point from the other side. Only 306 of the 170,000 observed attacks (arXiv:2103.04443), 0.18% affecting 48 networks, exceeded the victim’s port capacity, but those attacks averaged 21 minutes, and the study notes “these cases are not short bursts, but attacks that overwhelmed the port capacity for a notable time.” Interestingly, 82% of the affected networks had ports above 10 Gbps (arXiv:2103.04443), meaning the capacity-exceeding tail hits even well-provisioned operators.
So the tail behaves exactly opposite to the swarm: it is rare, it is large, it lasts long enough for a divert to engage, and no origin-side filter can absorb it because the link itself is full. This is the segment where on-demand scrubbing and purchased capacity still earn their cost. A botnet takedown that halves the terabit count is welcome, but it is also reversible; the Cloudflare report itself cautions that “variants continue to emerge,” and the booter takedown study watched a seized service resume operations on a new domain three days after its old one was seized. A buying decision should not assume the Q3 decline is permanent.
Matching attack class to architecture
The full mapping, with every frequency figure carrying its source caveat (vendor telemetry or pre-2026 academic measurement):
| Attack class | Observed frequency | Duration profile | Matching architecture | Latency budget |
|---|---|---|---|---|
| Sub-1-Gbps burst (booter swarm) | 98% of Cloudflare-mitigated attacks; +208% YoY | 96% under 10 min; purchased VIP attacks configured for 5 min | Always-on in-line scrubbing, or origin-side eBPF/XDP filtering | Effectively zero; must be autonomous |
| Port-saturating / capacity-exceeding | Small share of Cloudflare counts; IXP: 0.18% exceeded victim ports, most of them on links above 10 Gbps | Minutes to ~21 min average for capacity-exceeding events | Always-on in-line; automated network-side response if mature | Under ~1-2 min; IXP best case averaged 1.16 min |
| Terabit-class volumetric | 251 events in Q3 2026 (down from 805) | Long enough to engage; the 49.7-hour Mirai siege is the extreme | On-demand BGP divert to high-capacity scrubbing, or always-on at a large CDN | Minutes are acceptable; capacity is the constraint |
| Multi-day sustained campaign | Rare but observed (49.7 hours in Q3) | Hours to days | Scrubbing capacity plus upstream cooperation; origin-side filtering useless once the link is full | Engagement latency irrelevant; endurance and capacity dominate |
On the origin-side row, one feasibility result is worth knowing: an eBPF/XDP in-kernel filtering framework blocked over 97% of a 100 Mbps flood on a Raspberry Pi 4 with legitimate traffic unaffected. That is a testbed result at 100 Mbps (arXiv:2508.00851), so it proves the mechanism rather than production readiness. But it suggests the sub-1-Gbps class, which is nearly everything Cloudflare counted, is within reach of commodity host-side filtering for operators who cannot route through a CDN, such as game servers, VoIP, or self-hosted infrastructure with latency constraints.
What this evidence cannot establish
The limits deserve plain statement, because they bound how far the bottleneck thesis travels.
Every duration and volume figure here is single-vendor telemetry with a survivorship-shaped denominator: attacks Cloudflare mitigated, on a CDN-shaped traffic mix. Attacks that never touched Cloudflare’s network, or that succeeded against unprotected targets, are invisible to this distribution. The corroborating academic work, the IXP measurements and the booter purchases, predates 2026, so it supports the pattern’s durability rather than its current magnitude. Among the sources cited here, Cloudflare is the only one publishing a quarterly duration distribution; treating the shift as industry-wide would require a comparable distribution from an independent vendor. Until one is in hand, “the bottleneck has shifted” is a well-supported inference from one large vantage point, not an industry-wide result.
Nor does the evidence establish that on-demand diversion is always too slow: the IXP’s automated blackholing (70% of rules installed pre-detection, per the study) shows well-instrumented networks can respond inside the attack window, and the capacity-exceeding attacks in that study averaged 21 minutes, comfortably divertable.
Buy detection speed for the swarm, capacity for the tail
The decision resolves into a two-layer answer. Make autonomous, always-on mitigation the default layer: CDN-fronted scrubbing where your traffic can take that path, origin-side eBPF/XDP-style filtering where it cannot. That layer exists for the 96%-under-ten-minutes swarm (Cloudflare), where any detect-then-divert pipeline arrives after the attack it was meant to stop. Then keep on-demand BGP divert, or contracted scrubbing capacity, as insurance for the tail: the roughly 250 terabit-class events per quarter (Cloudflare) and multi-day sieges like the 49.7-hour Mirai attack, where engagement latency stops mattering and raw capacity is the whole game. Size paid bandwidth headroom to that tail, not to burst counts, and size it against measured delivered rates rather than booter advertising, which controlled tests found overstates volume by a factor of four.
The one caveat I would not skip: this allocation follows from Cloudflare’s distribution, and Cloudflare profits from the always-on conclusion. The logic of matching engagement latency to attack duration stands on its own, and the independent measurements point the same direction. But before restructuring a six-figure mitigation contract around it, get your own numbers: your provider’s detection-to-mitigation time in writing, and your traffic’s actual attack history. The swarm is fast. Your response has to be faster, and “faster” is a property of architecture, not of budget.
Frequently Asked Questions
How long did most DDoS attacks last in Cloudflare’s Q3 2026 report?
96% of the network-layer attacks it mitigated in July through September ended in under 10 minutes, and 98% stayed under 1 Gbps (Cloudflare, Q3 2026).
How much did booter services overstate their attack capacity?
the attacks delivered measured peaks of about 20 Gbps (NTP) and 10 Gbps (memcached), roughly 25% of the advertised rate.
Join the discussion
Share a useful perspective or ask a question about this article.