Absorbing a 40-million-request attack without anyone noticing.

A global nonprofit’s public site came under a sustained flood of automated traffic. The mandate: keep the site up for the people who needed it, without buying a bigger origin or an emergency vendor contract.

The situation

The traffic didn’t look like a textbook volumetric attack at first — it looked like success. Request counts climbed, origin CPU followed, and pages got slower for everyone. Under the hood, a rotating pool of clients was hammering the most expensive endpoints: search, dynamic pages, anything that bypassed the cache and made the origin work.

That’s the part that makes application-layer floods dangerous for lean organizations. The origin was sized for people, not for bots with infinite patience — and every request it burned on junk was capacity taken from a family or donor trying to reach the site.

The approach

Everything was done at the Cloudflare edge, in front of the origin — no new servers, no code changes to the application itself.

1. Read the traffic before touching anything. Firewall analytics and logs first: which paths, which ASNs, which client fingerprints, what the request cadence looked like. Rule one of mitigation is that you can’t rate-limit what you haven’t characterized — guessing produces rules that block donors and let bots through.
2. Rate-limit the expensive paths. Per-client thresholds on the endpoints the attack actually targeted, tuned just above real human usage patterns. Legitimate visitors never hit the limits; the bot pool hit them constantly and got turned away before the origin ever saw the request.
3. Managed challenges for the gray zone. Traffic that looked automated-but-uncertain got Cloudflare’s managed challenge — invisible to almost all real browsers, a dead end for headless clients. This is the humane middle ground between “allow” and “block”: nobody solves puzzles, but automation quietly fails.
4. A waiting room as the shock absorber. For the peaks, a waiting room capped concurrent load at what the origin could serve well, queuing the overflow with an honest page instead of letting every request degrade into a timeout. Graceful degradation, chosen in advance, instead of accidental failure.

The outcome

The stack held. More than forty million malicious requests were absorbed at the edge over the course of the attack — rejected, challenged, or queued — while the origin kept serving real visitors at normal speed. No emergency capacity was purchased. No maintenance page went up. Most people never knew anything happened, which is exactly the point.

The configuration stayed in place afterward as a permanent posture: the rate limits and challenge rules now absorb the background radiation of the internet — scrapers, credential stuffers, vulnerability scanners — every day, quietly.

tech <cloudflare; rate limiting; managed challenge; waiting room; firewall analytics>

Facing something similar?

If your site is getting slower and your traffic graphs are getting weirder, the diagnosis is usually a day’s work and the fix rarely requires new infrastructure. Email me — or run your own domain through the live health check first.