Mean time to detect (MTTD) is usually described as how quickly monitoring notices an attack. That holds only for the attacks monitoring was built to see, and a DDoS test exists to find out which attacks those are. Formally it is the average elapsed time from the first attack packet to the moment detection recognises that an attack is under way. It is the front half of time to mitigation: nothing can be filtered until it is seen, so detection latency sets the floor on how fast any mitigation, automatic or human, can engage.
Where the minutes come from
Detection is rarely one delay. It is a stack of intervals, each set by a configuration value someone chose for a different reason.
Flow telemetry is exported in batches. Classic NetFlow on many routers defaults to a 30-minute active timeout, which means a long-lived flow is not reported until half an hour in unless someone shortened it. DDoS deployments typically lower it to around a minute, and that minute is still the floor.
Cloud metrics work the same way. A metric published at one-minute granularity, feeding an alarm that requires three consecutive breaching periods, cannot detect anything in less than three minutes however large the flood.
Then the analysis. Anomaly detection compares traffic against a learned baseline, and a baseline that adapts can be taught. An attack that ramps more slowly than the baseline relearns gets absorbed into "normal", and the alarm never fires.
Why the mean misleads
The word "mean" hides two problems. The first is spread: an MTTD of 90 seconds can be an average of 20-second detections on volumetric floods and 6-minute detections on application-layer ones. The vector that takes six minutes is the one an attacker will choose.
The second is worse. An attack that is never detected has no detection time, so it simply drops out of the average. A stack can report an excellent MTTD precisely because it missed the hard cases entirely. Those misses belong in the false negative rate, reported beside MTTD, never folded into it.
"Detected" also needs pinning down. An alert firing and an engineer acknowledging it are different moments, and in a manual response model the gap between them, a page at 3 a.m., is often longer than the machine detection.
What a DDoS test measures
A test has one advantage no real incident does: it knows the exact second the attack began. In production, onset is reconstructed from logs after the fact, usually generously. Under test the clock starts on the first packet.
So a test records detection per vector and per rate, not as one number. It launches each attack class at several intensities, including a slow ramp, and logs when telemetry first showed it, when the alert fired, and when a human acknowledged it. The result is a distribution with the misses counted, which says where detection is fast, where it is slow, and where it is absent.
What those intervals mean for how a resilience posture is scored is worked through in the DDoS resilience score.