What do abortOnFail and delayAbortEval do to a k6 threshold, and when exactly does the abort fire?

## What the two keys are `abortOnFail` and `delayAbortEval` are the two optional keys of a threshold's **object form**. They cannot be expressed in the short string form at all, which is the reason the object form exists. ```javascript export const options = { thresholds: { http_req_duration: [ { threshold: 'p(95)<500', abortOnFail: true, delayAbortEval: '30s' }, ], http_req_failed: ['rate<0.01'], }, }; ``` - **`abortOnFail: true`** - if this expression evaluates false *while the test is still running*, k6 stops the run early instead of letting the remaining duration play out. - **`delayAbortEval: '30s'`** - a duration that arms the abort. Until the run has lasted longer than it, a failing expression is recorded as failing but is not allowed to stop anything. ## The two-second tick Neither key makes k6 watch a metric continuously. While a test is live, k6 re-evaluates every declared threshold **on a ticker that fires every two seconds**. So the practical meaning of "abort as soon as it fails" is "abort at the first two-second evaluation on which it is false". A rule that goes bad half a second after the run starts still costs you the rest of that two-second window, plus whatever the running iterations take to unwind. That tick is also the only place an abort can happen. When the run reaches its natural end, k6 evaluates the thresholds one last time to decide the verdict - and that final pass **discards the abort signal entirely**. So `abortOnFail` can only ever shorten a run; it never changes the pass or fail result you would have got anyway. ## How delayAbortEval is actually applied The rule is a strict comparison against elapsed run time, evaluated at each tick: 1. The expression is evaluated. If it passes, nothing happens. 2. If it fails, k6 marks the threshold failed and the metric tainted. 3. If `abortOnFail` is false, it stops there - **a `delayAbortEval` on a non-aborting threshold is inert**. 4. If `abortOnFail` is true, k6 asks whether `delayAbortEval` is set. If it is not, the abort fires now. 5. If it is set, the abort fires only when the configured duration is **strictly less than** the elapsed run time. At exactly the boundary the abort does not fire; it fires on the following tick. | `abortOnFail` | `delayAbortEval` | behaviour on a failing expression | |---|---|---| | absent or false | absent | recorded as failed, run continues to its end | | absent or false | `'30s'` | identical - the delay is ignored entirely | | true | absent | run stops at the first tick on which it fails | | true | `'30s'` | run stops at the first tick after 30 seconds of elapsed run time | The duration is written the way every other k6 duration is: `'10s'`, `'1m'`, `'1m30s'`. A bare number is also accepted and read as milliseconds, so `delayAbortEval: 30000` and `delayAbortEval: '30s'` are the same thing - but the string form is what the documentation shows and what a reviewer will recognise. ## The warm-up interaction nobody expects There is a second, quieter delay built into the in-run pass. When k6 evaluates thresholds during the run, it **skips any metric whose sink is still empty** - no samples, no evaluation. The consequences are worth stating plainly: - An `abortOnFail` threshold cannot fire before its metric has recorded at least one sample, whatever `delayAbortEval` says. A rule on a metric that never gets data will never abort anything. - The first evaluation therefore runs against however few samples have arrived in the first couple of seconds. On a `p(95)`, that can be a handful of requests - and a cold connection pool, a TLS handshake and a cold cache are all in them. That is the case `delayAbortEval` exists for. Setting it to cover your ramp-up means the abort is armed only once the numbers are made of steady-state traffic, rather than of the first few unlucky requests. Without it, an aggressive `p(95)` rule with `abortOnFail: true` will routinely kill a run two seconds in. ## What to check when it does not work - **Nothing aborted.** Confirm `abortOnFail` really is `true` on the entry, not on a sibling entry, and that the key is spelled exactly - k6 ignores unrecognised keys inside a threshold object without any warning, so `abortOnFailure: true` looks right and does nothing. - **It aborted too early.** Add or lengthen `delayAbortEval` to cover the ramp. - **It aborted with an odd delay.** Remember the two-second tick, and that k6 running in the cloud evaluates thresholds far less often - once a minute - so an abort there can lag by up to that long.