Slide 4 of 6

What k6 measures

Built-in metrics

k6 collects these metrics automatically for every HTTP request.

MetricWhat it measuresWhy it matters
http_req_durationTime from request start to response endThe primary measure of response speed
http_reqsTotal requests and requests per secondYour throughput under load
http_req_failedPercentage of requests that returned errorsError rate under load
checksPass rate of response assertionsWhether responses are correct, not just fast

Prefer percentiles for gates

p95 and p99 describe tail latency: how slow the slowest slice of requests were. Prefer them over avg, which can hide slow outliers. For pass/fail limits — the kind of target you might write into a service-level objective (SLO), like “95% of requests under 500ms” — start from p95 on http_req_duration, then add p99 when tail risk matters (payments, auth, checkout). Full metric definitions and extra aggregates live in HTTP metrics in the k6 docs.

When the numbers look wrong

SymptomFirst place to look
You doubled VUs but RPS barely movedRequests taking longer (http_req_duration), long sleep, or many requests per iteration eating the window
Errors spike with loadSaturation in the system under test, rate limits, or a script assumption (wrong header, shared test user)
You need one login for many VUssetup() to fetch a token once, pass data into VUs; still no shared mutable state between VUs

If you doubled VUs but requests per second barely moved, the links below explain why iteration pacing and open versus closed load models matter. Refer to Request rate and open vs closed models. For any run, anchor on http_req_duration and the summary tables.

Think about it

Pick one endpoint you might baseline later and a rough “too slow” number. You will reuse that intuition when you set thresholds in Module 3.

Script

k6 collects a set of built-in metrics automatically for every HTTP request. You don’t need to configure anything to get these.

The most important one is HTTP request duration, which measures how long each request takes from start to finish. k6 reports this as an average, a median, and percentiles like the ninetieth percentile and the ninety-fifth percentile. The percentile values are especially useful because they tell you how the slowest requests are performing, not just the average.

The HTTP requests metric tells you the total number of requests and the rate per second. This is your throughput. The HTTP request failed metric tracks the percentage of requests that returned errors.

Checks are assertions you add to your script. They validate that responses are correct, not just fast. A check might verify that the status code is 200 or that the response body contains expected data. Checks don’t stop the test when they fail, but they give you a pass rate you can set thresholds on.

Prefer ninety-fifth and ninety-ninth percentile latency over average when you set gates. If you double virtual users but requests per second barely move, use the troubleshooting table on this slide, then the request-rate and open-versus-closed model links when you need the underlying mechanics.

/
Previous Next