Asserting a minimum response time catches a login that stopped hashing passwords

The floor in the author's sketch was 20 ms, on a POST to /auth/login with a wrong password and an expected 401 ^[13]. Against the 336 ms the author measured ^[3], that sits about 17 times below the healthy path ^[2]. Two orders of magnitude faster than 336 ms is about 3.4 ms ^[1]. A string compare would land roughly 6 times under the floor ^[2]. Those ratios come from a single measurement on one app. They transfer only if your wrong-password path stays well above the floor on your fastest runner and the broken path stays well below it on your slowest.

The README argues that a floor is sturdier than a ceiling, because noise makes a measurement slower and almost never faster ^[11]. That holds for false alarms. A loaded runner will not make a 336 ms Argon2 check look like 3 ms. The same asymmetry works against detection. At these numbers, about 17 ms of added delay lifts a string compare over a 20 ms floor ^[5]. A floor also checks only that the path is slow; any other delay on the same path would satisfy it as well as the hash does.

Whole-second timestamps could never have told the two cases apart, since 336 ms and 3.4 ms both fall inside one second ^[4]. The author called the minimal image the right call and moved the feature into the config language instead ^[17]. "It had to be a keyword," the author wrote ^[7].

v0.12.0 gets the failure semantics right. A response under min_ms exits 1 and reports the measured time as evidence, while exit 2 stays reserved for "couldn't observe" ^[9]. "A login answering in 2 ms is wrong, not unavailable," the author wrote ^[10]. Declaring min_ms above max_ms is a config error ^[12], so nobody can commit a check that no response could satisfy.

The v0.13.1 fix is the same class of bug, found inside the runner. Since v0.6.0, captured output had been capped in memory, and the contains and absent rules ran against that capped copy ^[15]. Past the bound, a contains could fail on output that held the pattern, and an absent could pass over a FATAL ^[15]. v0.13.1 evaluates the rules line by line as output arrives and keeps the bounded copy for diagnosis only ^[15]. "The cap limits what you keep as evidence, never what you check," the author wrote ^[16]. Two dogfooding checks now cover both directions ^[15].