The k6 vocabulary

For the performance tests in this journey’s paths, k6 derives latency, throughput, and error metrics from the HTTP requests your script makes. Checks only appear when you define them; this journey adds checks on every path. The table below explains these metrics.

Percentiles (p50, p90, p95, p99) summarize how most requests behaved on the slow end; this journey leans on p95 for thresholds. Refer to HTTP metrics when you need the full set of aggregates.

Thresholds, exit codes, and CI

In k6, thresholds on built-in metrics yield a clear pass or fail for the run, and a breach exits with code 99 so a continuous integration job can stop the pipeline without a human reading graphs first. You usually set those thresholds from goals you already use in operations, for example a p95 latency budget for an API or page-backed route, and a cap on error rate so timeouts and failed responses stay rare under representative load. That pairing of scripted limits and a process exit code is how this journey automates quality gates; other load-testing tools expose their own failure and reporting models, and many also support response assertions similar to k6 checks.

The testing spectrum

Other common test types compare results against your baseline. That is why baseline comes first.