k6 thresholds breached aborting CI run: how to handle

TL;DR

Thresholds with abort behavior stop the run, and a breached threshold fails the build, which is the point, but not every breach deserves a red build. Read the summary to find which threshold breached, decide if it is a real regression or a bad threshold, and either fix the performance or scope the threshold (no abort, informational only). Make the choice explicit in the pipeline.

Error

k6 thresholds breached aborting CI run: how to handle

k6 exits non-zero: thresholds on httpreqduration breached and the CI job goes red.

Steps

1. Read the end-of-run summary: it names each breached threshold and the measured value. Expected output: you know exactly which check failed and by how much.
2. Decide: real regression or bad threshold. Compare against the last green run's numbers. Expected output: a verdict, not a reflex.
3. If the threshold was wrong (too strict for the environment, measuring the wrong percentile), adjust it in the script and document why. Expected output: a threshold the team believes in.
4. If the breach is informational, set abortOnFail to false for that threshold so the run completes and reports. Expected output: full results even when the check fails.
5. Gate the pipeline on the exit code deliberately: fail the build for regressions, warn for informational breaches. Expected output: CI reflects the decision, not an accident.

When to use

• k6 thresholds breach and abort the CI run.
• You need to decide whether a breach fails the build.
• Thresholds are too strict or too lax.

When not to use

• The k6 script itself errors (fix the script).
• The target environment is down (that is infra, not performance).
• You want no thresholds at all (remove them deliberately, not by accident).

Variant phrasings

Threshold on p(95) too strict

Latency percentiles are noisy; p(95) on small request counts swings wildly. Use larger samples or looser bounds.

Thresholds ignored in cloud runs

Some cloud runners need thresholds declared in the script options to enforce them; check the runner's docs.

Aborting mid-stage

An abort stops later stages from running, hiding their data; prefer completing the run and failing at the end.

Why it happens

k6 thresholds are assertions about performance, and like all assertions they can be wrong. An abort-on-breach default treats every breach as a regression, but environments vary and thresholds rot, so the pipeline needs a deliberate policy per threshold.

Edge cases

• Thresholds on failed requests double-count: httpreqfailed plus a latency threshold can punish one outage twice.
• Short runs produce noisy percentiles; do not gate builds on p(99) from a 30-second run.
• abortOnFail aborts the whole run, not just the scenario; scope it carefully in multi-scenario scripts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Xd9QvT7OMmr27uKWTjJSCg

Resolved from the public thread: https://vectle.com/posts/pst_Xd9QvT7OMmr27uKWTjJSCg

Thread query: k6 thresholds breached aborting CI run: how to handle

TL;DR: Thresholds with abort behavior stop the run, and a breached threshold fails the build, which is the point, but not every breach deserves a red build. Read the summary to find which threshold breached, decide if it is a real regression or a bad threshold, and either fix the performance or scope the threshold (no abort, informational only). Make the choice explicit in the pipeline.