deep

[DEEP RESEARCH] The Attack Ended Before the Escalation Did

Short DDoS bursts can outlast their traffic. Test when customers recover—not when a provider declares mitigation active.

Wes

Wes

— 5 min read
Share
[DEEP RESEARCH] The Attack Ended Before the Escalation Did
The attacker clocked out. The queue did not.

A distributed denial-of-service attack does not have to stay on the wire until your incident call ends. It only has to leave something important exhausted.

Cloudflare's latest quarterly report makes that timing problem worth checking: 96% of the network-layer attacks it observed in Q3 2026 ended in under ten minutes; 98% stayed below one gigabit per second. Those are two distributions within one provider's telemetry—not a census of the Internet, and not measurements of application recovery. [1]

Our judgment: Buy DDoS protection against the time your critical transactions can tolerate impairment, not just the traffic a provider says it can absorb.

For a service that fails before a ticket-driven activation completes, more advertised capacity does not repair the operating model. Continuously active or automatic protection is the stronger starting point. A tested on-demand design can still be appropriate when the complete activation and recovery path fits the service's tolerance with margin.

A short attack is a test case, not proof of a short outage

The report gives defenders a reason to test brief bursts. It does not tell you whether your first failure will be an access circuit, a firewall's connection table, or a database behind an expensive request.

AWS documents the distinction: a network flood can saturate capacity; a TCP SYN flood can exhaust connection state; an application flood can use requests that are valid for the target. These are different ways to make customers wait. Cloudflare's network-layer percentages do not establish how common the application-layer cases are. [2]

One useful check now: take a recent event or authorized exercise and line up the provider's “mitigation active” timestamp with a synthetic login or other critical transaction. If filtering was active while transactions still failed, keep the availability incident open and investigate the remaining bottleneck. That finding does not, by itself, prove that filtering failed—or that DDoS caused every downstream error.

The green dashboard is evidence of a control doing something. It is not a customer completing checkout.

Below the tear: how to distinguish activation delay, bypass and downstream exhaustion—and use that evidence to choose protection at renewal.

Diagnose the delay before buying the upgrade

A useful review separates when malicious traffic was filtered from when legitimate work became possible again.

Read more