Grafana Learn
Sign in Sign up
Section 2 · Your first performance test

Built-in metrics that k6 collects automatically

Estimated time: 2 min

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, such as a service-level objective (SLO) that requires 95% of requests to complete in 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.