Metrics on Grafana Labs

Built-in metrics

Mon, 21 Sep 2026 15:16:28 +0000

Built-in metrics

Every k6 test emits built-in and custom metrics. Each supported protocol also has its specific metrics.

Standard built-in metrics

k6 always collects the following metrics, no matter what protocol the test uses:

Metric Name	Type	Description
checks	Rate	The rate of successful checks. In the end-of-test summary, this metric is displayed as three values: `checks_total` (Counter), `checks_succeeded` (Rate), and `checks_failed` (Rate). These display values are not emitted to output backends and cannot be used in thresholds.
data_received	Counter	The amount of received data. This example covers how to track data for an individual URL.
data_sent	Counter	The amount of data sent. Track data for an individual URL to track data for an individual URL.
dropped_iterations	Counter	The number of iterations that weren’t started due to lack of VUs (for the arrival-rate executors) or lack of time (expired maxDuration in the iteration-based executors). Refer to Dropped iterations for more details.
iteration_duration	Trend	The time to complete one full iteration, including time spent in `setup` and `teardown`. To calculate the duration of the iteration’s function for the specific scenario, try this workaround.
iterations	Counter	The aggregate number of times the VUs execute the JS script (the `default` function).
vus	Gauge	Current number of active virtual users
vus_max	Gauge	Max possible number of virtual users (VU resources are pre-allocated, to avoid affecting performance when scaling up load).

HTTP-specific built-in metrics

These metrics are generated only when the test makes HTTP requests.

Note
For all http_req_* metrics, the timestamp is emitted the end of the request. In other words, the timestamp happens when k6 receives the end of the response body, or the request times out.

Metric Name	Type	Description
http_req_blocked	Trend	Time spent blocked (waiting for a free TCP connection slot) before initiating the request. `float`
http_req_connecting	Trend	Time spent establishing TCP connection to the remote host. `float`
http_req_duration	Trend	Total time for the request. It’s equal to `http_req_sending + http_req_waiting + http_req_receiving` (i.e. how long did the remote server take to process the request and respond, without the initial DNS lookup/connection times). `float`
http_req_failed	Rate	The rate of failed requests according to setResponseCallback.
http_req_receiving	Trend	Time spent receiving response data from the remote host. `float`
http_req_sending	Trend	Time spent sending data to the remote host. `float`
http_req_tls_handshaking	Trend	Time spent handshaking TLS session with remote host
http_req_waiting	Trend	Time spent waiting for response from remote host (a.k.a. “time to first byte”, or “TTFB”). `float`
http_reqs	Counter	How many total HTTP requests k6 generated.

Browser metrics

The k6 browser module emits its own metrics based on the Core Web Vitals.

These core metrics will evolve over time when technology changes, but for now, k6 tracks the following core web vitals:

Metric name	Description
browser_web_vital_cls	Measures the visual stability on a webpage by quantifying the amount of unexpected layout shift of visible page content. Refer to Cumulative Layout Shift for more information.
browser_web_vital_inp	A metric that measures a page’s responsiveness. Refer to Interaction to Next Paint for more information.
browser_web_vital_lcp	Measures the time it takes for the largest content element on a page to become visible. Refer to Largest Contentful Paint for more information.

Other Web Vitals

Apart from the Core Web Vitals, the browser module also reports Other Web Vitals.

Metric name	Description
browser_web_vital_fcp	Measures the time it takes for the browser to render the first DOM element on the page, whether that’s a text, image or header. Refer to First Contentful Paint for more information.
browser_web_vital_ttfb	Measures the time it takes between the browser request and the start of the response from a server. Refer to Time to First Byte for more information.

Built-in WebSocket metrics

k6 emits the following metrics when interacting with a WebSocket service through the k6/websockets or legacy k6/ws API.

Metric name	Type	Description
ws_connecting	Trend	Total duration for the WebSocket connection request.
ws_msgs_received	Counter	Total number of messages received
ws_msgs_sent	Counter	Total number of messages sent
ws_ping	Trend	Duration between a ping request and its pong reception
ws_session_duration	Trend	Duration of the WebSocket session. Time between the start of the connection and the end of the VU execution.
ws_sessions	Counter	Total number of started WebSocket sessions.

Built-in gRPC metrics

k6 emits the following metrics when it interacts with a service through the gRPC API.

Metric Name	Type	Description
grpc_req_duration	Trend	Time to receive response from remote host
grpc_streams	Counter	Total number of started streams
grpc_streams_msgs_received	Counter	Total number of messages received
grpc_streams_msgs_sent	Counter	Total number of messages sent

Note
Steams-related metrics (grpc_streams*) are available only on k6 version 0.49.0 or higher or when using the k6/experimental/grpc module, which is available on k6 version 0.45.0.

Create custom metrics

Mon, 21 Sep 2026 15:16:28 +0000

Create custom metrics

Besides the built-in metrics, you can create custom metrics. For example, you can compute a metric for your business logic, or use the Response.timings object to create a metric for a specific set of endpoints.

Each metric type has a constructor to create a custom metric. The constructor creates a metric object of the declared type. Each type has an add method to take metric measurements.

If you need help constructing a custom metric, read the following sections of this document. They document the procedure and provide examples. If you’re comfortable with these already, you might prefer to read the reference documentation for each metric constructor. Each topic has examples to make a custom metric and create thresholds from it.

Create a custom metric

Note
Custom metrics must be created in init context. This limits memory and ensures that k6 can validate that all thresholds are evaluating defined metrics.

The generic procedure to create a custom metric is as follows:

Import the k6/metrics module. Optionally, specify the type of metrics you want to create with a named import:
JavaScript
```
import { Trend } from 'k6/metrics';
```
In init context, construct a new custom-metric object.

For example, the following creates a custom trend. The object in the script is called myTrend, and its metric appears in the results output as waiting_time.
JavaScript
```
const myTrend = new Trend('waiting_time');
```
In the VU iteration code, use the add method to take a measurement.

Example: create a trend metric for waiting time

This VU code makes a request then adds the timing value of the request to the myTrend object.

import http from 'k6/http';
import { Trend } from 'k6/metrics';

const myTrend = new Trend('waiting_time');

export default function () {
  const r = http.get('https://quickpizza.grafana.com/');
  myTrend.add(r.timings.waiting);
  console.log(myTrend.name); // waiting_time
}

View custom metric results

Custom metrics appear in Results output in both the end-of-test summary and in the granular data points. Each metric type has specific aggregation methods. You can also optionally tag any value for a custom metric. You can use these tags to filter test results.

Here’s how the output of the preceding script might look in the end-of-test summary. Since the metric is a trend, k6 calculates various trends based on the number of values and their summation.

$ k6 run script.js

  ...
  INFO[0001] waiting_time                                  source=console

  ...
  iteration_duration.............: avg=1.15s    min=1.15s    med=1.15s    max=1.15s    p(90)=1.15s    p(95)=1.15s
  iterations.....................: 1     0.864973/s
  waiting_time...................: avg=265.245396 min=265.245396 med=265.245396 max=265.245396 p(90)=265.245396 p(95)=265.245396

Note
Custom metrics are collected from VU threads only at the end of a VU iteration. For long-running scripts, custom metrics might appear only after the test runs a while.

The k6/metrics has examples for defining each type of custom metric, and for defining a threshold on the metric.

Metrics on Grafana Labs

Built-in metrics

Built-in metrics

Standard built-in metrics

HTTP-specific built-in metrics

Browser metrics

Other Web Vitals

Built-in WebSocket metrics

Built-in gRPC metrics

Create custom metrics

Create custom metrics

Create a custom metric

Example: create a trend metric for waiting time

View custom metric results

Read more