---
title: "What k6 measures | Grafana Labs"
description: "Built-in metrics that k6 collects automatically"
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

## Built-in metrics

k6 collects these metrics automatically for every HTTP request.

| Metric              | What it measures                            | Why it matters                               |
|---------------------|---------------------------------------------|----------------------------------------------|
| `http_req_duration` | Time from request start to response end     | The primary measure of response speed        |
| `http_reqs`         | Total requests and requests per second      | Your throughput under load                   |
| `http_req_failed`   | Percentage of requests that returned errors | Error rate under load                        |
| `checks`            | Pass rate of response assertions            | Whether 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](/docs/k6/latest/using-k6/metrics/reference/#http) in the k6 docs.

## When the numbers look wrong

| Symptom                                  | First place to look                                                                                          |
|------------------------------------------|--------------------------------------------------------------------------------------------------------------|
| **You doubled VUs but RPS barely moved** | Requests taking longer (`http_req_duration`), long `sleep`, or many requests per iteration eating the window |
| **Errors spike with load**               | Saturation in the system under test, rate limits, or a script assumption (wrong header, shared test user)    |
| **You need one login for many VUs**      | `setup()` 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](/docs/k6/latest/testing-guides/api-load-testing/#request-rate) and [open vs closed models](/docs/k6/latest/using-k6/scenarios/concepts/open-vs-closed/). For any run, anchor on [`http_req_duration`](/docs/k6/latest/using-k6/metrics/reference/#http) 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.