All DDoS Definitions
DDoS Testing Definition

Time-to-Recovery (TTR)

Unlike time-to-mitigation, which ends when scrubbing takes hold, time-to-recovery (TTR) starts there. It is the interval a DDoS test clocks from the moment the flood is filtered to the moment the service is back at its normal baseline: error rates nominal, latency percentiles restored, queues drained, connection pools refilled. The attack traffic can be gone for minutes while users still feel it.

Time-to-recovery: the settling tail after filtering starts attack onset scrubbing engages baseline restored baseline service health time TTM: how fast filtering starts TTR: how long the system needs to settle back Filtering the flood is not health: conntrack tables, worker pools and cold caches keep the tail degraded. BlackNeuron™
Diagram of time-to-recovery: the settling tail from when scrubbing engages to when the service returns to its performance baseline

Why the tail exists

Filtering stops new damage. It does nothing about state the attack already left behind, and each kind of leftover clears on its own clock.

Tables clear slowly. A Linux connection-tracking entry for an established TCP flow is kept for five days by default unless the connection closes, so a TCP connection flood that completed its handshakes can leave the table near its ceiling long after the traffic ends. Sockets in TIME_WAIT linger for 60 seconds on Linux, holding the port pairs they used.

Queues drain at the gap between service rate and arrival rate. A backlog built at full attack load only empties as fast as the spare capacity allows, and that spare capacity is thin at the moment real users return.

Caches come back cold. A cache-busting flood evicts the hot set, so every request after the attack goes to the origin until the cache refills. Circuit breakers stay open for their configured sleep window, and autoscaled capacity may already be scaling in.

The return can be its own spike

Recovery is rarely a gentle slope. Every client that failed during the attack retries when the service answers again: browsers reload, mobile apps reconnect, queued jobs resubmit. That synchronised return can push a recovering system back over the edge, which is why a TTR curve sometimes shows a second, smaller dip just after mitigation looked done.

Withdrawing the mitigation can do the same. If the diversion or emergency rule is removed while traffic is still elevated, the service takes a second hit, and the recovery clock restarts.

Time-to-recovery: the slow climb after the flood is filtered pre-attack baseline requests served within SLO time normal service attack at full force filtered, backlog draining back within tolerance TTR is the climb from filtering engaged to a stable baseline, not the depth of the dip BlackNeuron™
Animated time-to-recovery: the share of requests served within target falls during the attack and then climbs back slowly after filtering engages, as backlogs drain and caches refill, until it settles within tolerance of the pre-attack baseline

What a DDoS test measures

A test defines "recovered" before it starts: a tolerance band around the pre-attack baseline for error rate and p99 latency, and how long the service must stay inside it, so a brief good minute is not mistaken for recovery. It then clocks from filtering engaged to the start of that stable window.

The more useful output is the order in which things came back. Which component returned last, the table, the queue, the cache or the database pool, is where the fix belongs. A test can also stop the attack outright and compare, which separates the tail caused by leftover state from the tail caused by mitigation still running.

Inside a service mesh, recovery takes longer still, because retries between services keep the load up after the edge has gone quiet. DDoS Testing for Microservices covers that case.