DDoS Mitigation KPIs That Actually Matter

Nearly every DDoS report leads with the same figure: how much attack traffic was blocked. It is the easiest number to produce and the hardest to use, because it describes the attacker’s behaviour rather than the defence’s quality.

A defence that drops everything blocks 100% of the attack. The service is down. The report is excellent.

At a glance

Appliance	Metric	Who can measure it	Why it is reported or not
Gbps or packets blocked	The device, trivially	Always reported; cannot be acted on
Time to detect	You, from your own timeline	Reported; often measured from the wrong start point
Time to mitigate	You, from your own timeline	Reported; frequently confused with time to detect
Legitimate traffic survival	Only you	Rarely reported; the number the business bought
False-positive rate	Only you	Rarely reported; needs a baseline to exist
Operator interventions	You, by counting	Never reported; predicts operating cost
Time to recover	You, from application metrics	Rarely reported; where late-clearing state shows up

The middle column is the point. Five of the seven can only come from your own instrumentation, which is why a supplier's report has never been a complete answer.

1. Time to detect

From the first packet of the attack to the first alert a human sees.

The trap is the start point. Systems measure from when their own detection fired, which guarantees a flattering number and hides the interval you actually care about. Reconstruct the true start from packet captures or flow records afterwards, and measure from there.

Report it with the detection method that fired, because a threshold crossing at four minutes and a behavioural verdict at forty seconds are different capabilities being exercised.

2. Time to mitigate

From the first packet to the point where impact is measurably reduced and stays reduced.

Two distinctions do most of the work. Automated versus assisted: mitigation that began without a human is a different figure from one that waited for someone to approve it, and reporting them together hides the operating cost. Reduced versus resolved: partial suppression at two minutes and full suppression at eleven are both worth recording, and a single number conceals both.

For diversion-based designs this figure includes route convergence, which is the structural reason out-of-path on-demand architectures cannot compete on it.

3. Legitimate traffic survival

The fraction of genuine transactions that completed during the attack, against the same measurement from before it.

This is the number the business thought it was buying, and it is absent from nearly every incident report. It requires two things that must exist in advance: continuous measurement of a genuine business transaction, and a baseline from an ordinary period.

Both are cheap to build and neither can be retrofitted after an incident. An organisation without them cannot answer the only question its executives will ask, which is whether customers could still use the service.

The measurement discipline, including the sample-size arithmetic that makes small rates unmeasurable in short windows, is in testing false positives.

4. False-positive rate

The fraction of legitimate traffic refused by the defence rather than by the attack.

Distinguish it from survival: survival counts everything that failed, including what the attack itself broke. This counts what your own control refused. The difference is the cost of the defence, and separating the two requires a control path that was not behind the mitigation.

Report it with a denominator. “Zero false positives” over two thousand samples cannot distinguish one-in-a-thousand from one-in-a-million.

5. Sustained packet rate under mitigation

The packet rate the defence held while actually mitigating, at the frame size observed.

Two figures worth separating: the rate at which it operated during the event, and the rate at which behaviour changed if the event reached that point. The second is the real capacity number and it can only be found in a test lab, not during production.

Always record the frame size. Without it the figure cannot be compared to a datasheet, to another product, or to your own previous incident.

6. Operator interventions required

How many times a human had to change something for mitigation to work or keep working.

Nobody reports this, and it is the single strongest predictor of what the product will cost to run. A defence that handles an attack with zero interventions and one that handles the same attack with nine are wildly different products at the same purchase price, and no evaluation will reveal the difference unless somebody counts.

Count the interventions, and record which required a decision nobody present was authorised to make. That second count is an organisational finding rather than a technical one, and it usually explains most of the elapsed time.

7. Time to recover

From the end of the attack to the return of normal service metrics.

Recovery is not free and is frequently longer than expected. Blocks expire on timers, quarantine lists clear slowly, connection pools refill, caches rebuild, and clients retry in a synchronised wave that looks like a second attack. An estate that stops measuring when the attack stops never sees any of this.

Building the report

Seven lines, and the discipline is in the qualifiers rather than the numbers:

Metric	Value	Qualifier that must accompany it
Time to detect		Start point, and which detection fired
Time to mitigate		Automated or assisted; reduced or resolved
Legitimate survival		Baseline used, and sample size
False-positive rate		Denominator, and how the control path was isolated
Sustained packet rate		Frame size observed
Operator interventions		How many needed absent authority
Time to recover		Which metric was used to define normal

That table belongs in the post-incident review and, with thresholds attached, in the acceptance criteria before purchase. A supplier who will commit to the first two and not the third is telling you which of them they can control.