---
title: "Performance testing with k6 | Grafana Labs"
description: "The k6 vocabulary and where automated performance testing fits in your workflow"
---

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

## The k6 vocabulary

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

| Metric                             | What it measures                                  | How k6 reports it                                                 |
|------------------------------------|---------------------------------------------------|-------------------------------------------------------------------|
| **Latency** (`http_req_duration`)  | Response time per request                         | Percentiles: p50, p90, p95, p99                                   |
| **Throughput** (`http_reqs`)       | How much HTTP traffic your script generated       | Total request count; summary also shows average rate (per second) |
| **Error rate** (`http_req_failed`) | Percentage of failed requests                     | Rate (0.00 = no errors)                                           |
| **Checks**                         | Response assertions (correctness, not just speed) | Pass rate when your script defines checks                         |

**Percentiles** (p50, p90, p95, p99) summarize how most requests behaved on the slow end; this course leans on **p95** for thresholds. Refer to [HTTP metrics](/docs/k6/latest/using-k6/metrics/reference/#http) 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 course 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.

| Test type    | Question it answers                      | This course?                                                         |
|--------------|------------------------------------------|----------------------------------------------------------------------|
| **Baseline** | “What does normal look like?”            | Yes – Module 3                                                       |
| **Stress**   | “Where does performance degrade?”        | No – see [k6 test types](/docs/k6/latest/testing-guides/test-types/) |
| **Spike**    | “Can we survive a sudden traffic burst?” | No – see [k6 test types](/docs/k6/latest/testing-guides/test-types/) |
| **Soak**     | “Does anything break over hours?”        | No – see [k6 test types](/docs/k6/latest/testing-guides/test-types/) |