running a DDoS tabletop exercise with your team sounds like a narrow topic. It turns out to touch almost every part of how an edge network behaves under attack.
What we changed
We moved the decision from a single threshold to a continuous score, added an explanation to every decision and made every rule testable against historical traffic before it goes live.
The result is fewer late-night pages for our analysts and — more importantly — fewer real users challenged by mistake.
Measuring success
We track three numbers for every incident: time to mitigation, the share of attack traffic that reached the origin, and the share of legitimate traffic that was challenged. The first should be under a second, the second under 0.1% and the third under 1%.
Those numbers go into every incident report, and they are the same numbers we are measured against in our SLA.
What actually happens during a flood
The first thing to fail during a layer 7 flood is almost never bandwidth. It is connection slots, worker processes or database connections on the origin — resources measured in hundreds or thousands, not gigabits. An attacker who can make each request expensive only needs a few thousand requests per second.
That is why we score requests before they are proxied. By the time a request reaches your origin, it has been attributed to a client, compared against that client’s history and weighed against the current load on the route it targets.
Why per-route baselines matter
A thousand requests per second to your homepage is Tuesday. A thousand requests per second to your password-reset endpoint is an attack. Global rate limits cannot tell the difference; per-route baselines can.
We learn the normal shape of traffic per route and per hour of the week, so a surge on a sensitive endpoint raises the risk score long before it approaches a global threshold.
Testing in production, safely
Every rule starts in log mode. We replay the previous seven days of traffic through it and show exactly which requests it would have affected before anyone can promote it to challenge or block.
This one feature has prevented more incidents than any detection we have ever shipped.
The numbers
Across the last quarter, 71% of challenged clients never attempted a solution, 24% solved one challenge and then behaved normally, and 5% solved challenges repeatedly while continuing to attack — the last group is where analysts spend their time.
Median added latency for legitimate visitors that were challenged was 280 ms on desktop and 410 ms on mid-range Android devices.
The economics behind it
A booter service rents out a 100 Gbps attack for less than the price of a pizza. Defending against it with bandwidth alone is a race you lose. Defending against it by making each malicious request cost more than it earns is a race you win.
This is the entire idea behind never metering attack traffic: our costs scale with filtering, not with your invoice.
We will follow up with the numbers from the next quarter.
Solid runbook advice. The DNS-at-2am point hit home.
Is the risk score exposed in the logs so we can build our own dashboards on it?
The billing model is what got our finance team on board, honestly.
Solid runbook advice. The DNS-at-2am point hit home.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Clear and practical, thanks.
Our auditors asked for exactly this kind of incident evidence under DORA.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.