Menu

Important: This documentation is about an older version. It's relevant only to the release noted, many of the features and functions have been updated or replaced. Please view the current version.

Open source

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 NameTypeDescription
checksRateThe rate of successful checks.
data_receivedCounterThe amount of received data. This example covers how to track data for an individual URL.
data_sentCounterThe amount of data sent. Track data for an individual URL to track data for an individual URL.
dropped_iterationsCounterThe 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_durationTrendThe 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.
iterationsCounterThe aggregate number of times the VUs execute the JS script (the default function).
vusGaugeCurrent number of active virtual users
vus_maxGaugeMax 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 NameTypeDescription
http_req_blockedTrendTime spent blocked (waiting for a free TCP connection slot) before initiating the request. float
http_req_connectingTrendTime spent establishing TCP connection to the remote host. float
http_req_durationTrendTotal 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_failedRateThe rate of failed requests according to setResponseCallback.
http_req_receivingTrendTime spent receiving response data from the remote host. float
http_req_sendingTrendTime spent sending data to the remote host. float
http_req_tls_handshakingTrendTime spent handshaking TLS session with remote host
http_req_waitingTrendTime spent waiting for response from remote host (a.k.a. “time to first byte”, or “TTFB”). float
http_reqsCounterHow 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:

Core Web VitalDescription
browser_web_vital_clsMeasures 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_fidMeasures the responsiveness of a web page by quantifying the delay between a user’s first interaction, such as clicking a button, and the browser’s response. Refer to First Input Delay for more information.
browser_web_vital_lcpMeasures 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.

Other Web VitalDescription
browser_web_vital_fcpMeasures 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_inpAn experimental metric that measures a page’s responsiveness. Refer to Interaction to Next Paint for more information.
browser_web_vital_ttfbMeasures 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 experimental or legacy websockets API.

Metric nameTypeDescription
ws_connectingTrendTotal duration for the WebSocket connection request.
ws_msgs_receivedCounterTotal number of messages received
ws_msgs_sentCounterTotal number of messages sent
ws_pingTrendDuration between a ping request and its pong reception
ws_session_durationTrendDuration of the WebSocket session. Time between the start of the connection and the end of the VU execution.
ws_sessionsCounterTotal 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 NameTypeDescription
grpc_req_durationTrendTime to receive response from remote host
grpc_streamsCounterTotal number of started streams
grpc_streams_msgs_receivedCounterTotal number of messages received
grpc_streams_msgs_sentCounterTotal number of messages sent

Note

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