We get asked about what to put in your DDoS runbook more than almost anything else, so here is the long answer.
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.
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.
Lessons for your own runbook
Know who can change DNS at two in the morning. Know your origin IPs and who can rotate them. Know which routes are expensive, and have a rate limit ready for each of them.
Most outages during attacks are not caused by the attack itself but by rushed changes made while under pressure.
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.
Challenges beat blocks
Blocking lists go stale within minutes when attackers rotate through residential proxies. Proof-of-work does not care where a request comes from; it only cares whether the client is willing to pay the cost.
For a real browser that cost is a few hundred milliseconds, once per session. For a botnet sending a million requests a minute it is a million puzzles a minute — and at that point the attack stops being cheap.
As always, questions and corrections are welcome at [email protected].
Interesting that most attacks are under ten minutes. Our experience is similar.
The billing model is what got our finance team on board, honestly.
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
Thanks! Yes — the risk score and its components are included in every log record.
Carpet bombing is nasty. Good to see a clear explanation of it.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Machine-readable ranges are at /ips.json and via the API.
The point about origin IPs leaking through certificate transparency logs is underrated.