Validate thresholds work
Adding thresholds to your script isn’t enough. You need to confirm they actually pass and fail as expected. In this milestone, you run the test twice: once to verify it passes under normal conditions, and once with a deliberately strict threshold to confirm it fails correctly.
To validate your thresholds, complete the following steps:
Run the test:
k6 run baseline.jsAt the top of the summary output, look for the THRESHOLDS section and verify that all thresholds pass:
THRESHOLDS checks ✓ 'rate>0.99' rate=100.00% http_req_duration ✓ 'p(95)<500' p(95)=54.42ms http_req_failed ✓ 'rate<0.01' rate=0.00%A ✓ next to each threshold means it passed. The
rate>0.99on the checks threshold means the check pass rate must be above 99%. This is not related to p99 latency. The exit code should be0, which signals success.Verify the exit code in your terminal:
echo $?The output should be
0.Now test that a threshold failure works correctly. Temporarily set a very strict latency threshold that your system can’t meet. Open
baseline.jsand change thehttp_req_durationthreshold:thresholds: { http_req_duration: ['p(95)<1'], http_req_failed: ['rate<0.01'], checks: ['rate>0.99'], },A p95 under 1 ms is impossible for any real HTTP request, so this threshold should fail.
Run the test again:
k6 run baseline.jsThe THRESHOLDS section now shows a ✗ next to the failed threshold:
THRESHOLDS checks ✓ 'rate>0.99' rate=100.00% http_req_duration ✗ 'p(95)<1' p(95)=54.42ms http_req_failed ✓ 'rate<0.01' rate=0.00%Verify the exit code is non-zero:
echo $?The output should be
99, which is k6’s exit code for threshold failures. This non-zero exit code is what CI/CD systems use to detect a failed test.Restore your original threshold value before continuing:
http_req_duration: ['p(95)<500'],
You’ve confirmed that your thresholds work in both directions: passing when metrics are within bounds and failing when they’re breached.
In the next milestone, you save your results to k6 Cloud for historical tracking and team visibility.