Real time on Grafana Labs

Amazon CloudWatch

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

Amazon CloudWatch

Note
The built-in StatsD output has been deprecated on k6 v0.47.0 and removed in v0.55.0. You can continue to stream metrics to StatsD by using the xk6-output-statsd extension, or using the OpenTelemetry output depending on your use case.

For more information on the reason behind this change, you can follow this issue in the k6 repository.

k6 can send metrics data to Amazon CloudWatch through the CloudWatch Agent by using the xk6-output-statsd extension. These metrics can then be visualized in dashboards.

This guide covers how to:

Run the CloudWatch agent
Run the k6 test
Visualize k6 metrics in Amazon CloudWatch

Before you begin

To use the StatsD output option, you have to build a k6 binary using the xk6-output-statsd extension. For more details, refer to StatsD.

Run the CloudWatch agent

We presume that you already have a machine that supports both running k6 and CloudWatch agent, which either runs a flavor of GNU/Linux or Windows. Just go ahead and download the suitable CloudWatch agent version for your operating system.

Create an IAM role to send metrics to CloudWatch via the agent. Then, if you are running on Amazon EC2, just attach the role to your EC2 instance, so that you can send metrics to CloudWatch. Otherwise, if you are running on-premises servers, follow this guide.
Download the CloudWatch Agent package suitable for your operating system. For example, on Debian 10 (Buster), we’ve used the following link. For other operating systems, please refer to this guide:
Bash
```
wget https://s3.amazonaws.com/amazoncloudwatch-agent/debian/amd64/latest/amazon-cloudwatch-agent.deb
```

Install the package:

sudo dpkg -i amazon-cloudwatch-agent.deb

Configure the agent to receive data from k6. For this, create a file called “/opt/aws/amazon-cloudwatch-agent/etc/statsd.json” and paste the following JSON config object into it. This configuration means that the agent would listen on port number 8125, which is the default port number for k6 and StatsD. The interval for collecting metrics is 5 seconds and we don’t aggregate them, since we need the raw data later in CloudWatch.
JSON
```
{
  "metrics": {
    "namespace": "k6",
    "metrics_collected": {
      "statsd": {
        "service_address": ":8125",
        "metrics_collection_interval": 5,
        "metrics_aggregation_interval": 0
      }
    }
  }
}
```

Run the following command to start the agent:

sudo amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/etc/statsd.json

You can check the status of the agent using the following command:
Bash
```
amazon-cloudwatch-agent-ctl -a status
```

Run the k6 test

Once the agent is running, you can run your test with:

K6_STATSD_ENABLE_TAGS=true k6 run --out output-statsd script.js

Make sure you’re using the k6 binary you built with the xk6-output-statsd extension.

You can look at the StatsD output page for configuration options.

Visualize k6 metrics in Amazon CloudWatch

Visualization of the exported metrics to CloudWatch is done by creating a dashboard and selecting desired metrics to be displayed.

Here’s an example dashboard we’ve created to visualize the test results.

The above dashboard is exported as JSON and is available here.

Apache Kafka

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

Apache Kafka

Apache Kafka is a stream-processing platform for handling real-time data. Using xk6-output-kafka extension, you can send k6 metrics in real-time to Kafka, and, optionally, ingest them from InfluxDB.

Build the k6 version

To build a k6 binary with the extension, first, make sure you have Go and Git installed on your machine.

Then, open your terminal and run the following commands:

# Install xk6
go install go.k6.io/xk6/cmd/xk6@latest

# Build the k6 binary
xk6 build --with github.com/grafana/xk6-output-kafka

... [INFO] Build environment ready
... [INFO] Building k6
... [INFO] Build complete: ./k6

xk6 will create the new k6 binary in the local folder.

Note
To learn more about how to build custom k6 versions, check out xk6.

Run the k6 test

You can configure the broker (or multiple ones), topic and message format directly from the command line parameter like this:

k6 run --out xk6-kafka=brokers=broker_host:8000,topic=k6

or if you want multiple brokers:

--out xk6-kafka=brokers={broker1,broker2},topic=k6,format=json

You can also specify the message format k6 will use. By default, it will be the same as the JSON output, but you can also use the InfluxDB line protocol for direct “consumption” by InfluxDB:

--out xk6-kafka=brokers=someBroker,topic=someTopic,format=influxdb

You can even modify some of the format settings such as tagsAsFields:

--out xk6-kafka=brokers=someBroker,topic=someTopic,format=influxdb,influxdb.tagsAsFields={url,myCustomTag}

Options

Here is the full list of options that can be configured and passed to the extension:

Name	Type	Description
`K6_KAFKA_BROKERS`	`string`	List of brokers
`K6_KAFKA_TOPIC`	`string`	The name of the topic to be sent
`K6_KAFKA_AUTH_MECHANISM`	`string`	Authentication mechanism. Default `none`.
`K6_KAFKA_SASL_USER`	`string`	Kafka User
`K6_KAFKA_SASL_PASSWORD`	`string`	Kafka User Password
`K6_KAFKA_SSL`	`boolean`
`K6_KAFKA_VERSION`	`string`	Kafka version. Default the latest
`K6_KAFKA_INSECURE_SKIP_TLS_VERIFY`	`boolean`	Whether should ignore TLS verifications
`K6_KAFKA_PUSH_INTERVAL`	`string`	Interval of the metrics’ aggregation and upload to the endpoint
`K6_KAFKA_FORMAT`	`string`	Message format. `json` or `influxdb`
`K6_KAFKA_LOG_ERROR`	`boolean`	Boolean indicating to log kafka errors

CSV

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

CSV

You can output granular data points in CSV format. To do so, use k6 run with the --out flag. Pass the path for your CSV file as the flag argument:

k6 run --out csv=test_results.csv script.js

You can also get the results gzipped, like this:

k6 run --out csv=test_results.gz script.js

To inspect the output in real time, you can use a command like tail -f on the file you save:

tail -f test_results.csv

CSV format

The CSV result file will look something like this:

metric_name,timestamp,metric_value,check,error,error_code,group,method,name,proto,scenario,status,subproto,tls_version,url,extra_tags
http_reqs,1595325560,1.000000,,,,,GET,http://test.k6.io,HTTP/1.1,default,200,,,http://test.k6.io,
http_req_duration,1595325560,221.899000,,,,,GET,http://test.k6.io,HTTP/1.1,default,200,,,http://test.k6.io,
http_req_blocked,1595325560,225.275000,,,,,GET,http://test.k6.io,HTTP/1.1,default,200,,,http://test.k6.io,
http_req_connecting,1595325560,217.680000,,,,,GET,http://test.k6.io,HTTP/1.1,default,200,,,http://test.k6.io,
http_req_tls_handshaking,1595325560,0.000000,,,,,GET,http://test.k6.io,HTTP/1.1,default,200,,,http://test.k6.io,
http_req_sending,1595325560,0.112000,,,,,GET,http://test.k6.io,HTTP/1.1,default,200,,,http://test.k6.io,
http_req_waiting,1595325560,220.280000,,,,,GET,http://test.k6.io,HTTP/1.1,default,200,,,http://test.k6.io,
http_req_receiving,1595325560,1.507000,,,,,GET,http://test.k6.io,HTTP/1.1,default,200,,,http://test.k6.io,
vus,1595325560,1.000000,,,,,,,,,,,,,
vus_max,1595325560,20.000000,,,,,,,,,,,,,
checks,1595325561,1.000000,status is 200,,,,,,,default,,,,,
checks,1595325561,0.000000,response body,,,,,,,default,,,,,
data_sent,1595325561,76.000000,,,,,,,,default,,,,,
data_received,1595325561,11045.000000,,,,,,,,default,,,,,
iteration_duration,1595325561,1449.049580,,,,,,,,default,,,,,
iterations,1595325561,1.000000,,,,,,,,default,,,,,

Each entry in the report represents a metric, metric_name, along with its value, metric_value, at time, timestamp. If an error happens, then the error along with the error_code fields will be populated.

CSV options

k6 provides a few options to help you configure your CSV output:

option	Configures	Possible values	Default	Env. variable
`saveInterval`	The time intervals at which k6 writes to the CSV	Either a string with time units(`"1m45s"`), or a number of milliseconds	`"1s"`	`K6_CSV_SAVE_INTERVAL`
`timeFormat`	The timestamp format	unix, unix_nano, unix_micro, unix_milli, rfc3339, rfc3339_nano	unix	`K6_CSV_TIME_FORMAT`
`fileName`	The file name and path where output is saved	N/A	`file.csv`	`K6_CSV_FILENAME`

Datadog

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

Datadog

Note
The built-in StatsD output has been deprecated on k6 v0.47.0 and removed in v0.55.0. You can continue to stream metrics to StatsD by using the xk6-output-statsd extension, or using the OpenTelemetry output depending on your use case.

For more information on the reason behind this change, you can follow this issue in the k6 repository.

k6 can send metrics to Datadog. That allows visualizing and correlating performance testing metrics with other monitored metrics in Datadog.

This guide covers how to:

Run the Datadog Agent
Run the k6 test
Visualize in Datadog

Before you begin

To use the StatsD output option, you have to build a k6 binary using the xk6-output-statsd extension. For more details, refer to StatsD.

Run the Datadog Agent

To get k6 metrics into Datadog, k6 sends metrics through the Datadog Agent, which collects, aggregates, and forwards the metrics to the Datadog platform.

Run the Datadog Agent service as a Docker container with this command:

DOCKER_CONTENT_TRUST=1 \
docker run --rm -d \
    --name datadog \
    -v /var/run/docker.sock:/var/run/docker.sock:ro \
    -v /proc/:/host/proc/:ro \
    -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \
    -e DD_SITE="datadoghq.com" \
    -e DD_API_KEY=<YOUR_DATADOG_API_KEY> \
    -e DD_DOGSTATSD_NON_LOCAL_TRAFFIC=1 \
    -p 8125:8125/udp \
    datadog/agent:latest

For DD_SITE, make sure to use the correct Datadog site URL.

Replace <YOUR_DATADOG_API_KEY> with your Datadog API key.

Note
For additional information, refer to the Datadog Docker Agent documentation.

DogStatsD

The Datadog agent includes the DogStatsD service to collect and aggregate metrics. DogStatsD implements the StatsD protocol with some extensions. For example, DogStatsD tagging allows to collect k6 metrics with tags to distinguish between requests for different URLs, response statuses, groups, etc.

The instruction above runs the DogStatsD service in a Docker container, but it’s also possible to run it either as Host Agent, Kubernetes, and Helm.

Run the k6 test

Once the Datadog Agent service is running, run the k6 test and send the metrics to the Agent with:

K6_STATSD_ENABLE_TAGS=true k6 run --out output-statsd script.js

Make sure you’re using the k6 binary you built with the xk6-output-statsd extension.

You can look at the StatsD output page for configuration options.

Visualize in Datadog

While running the test, k6 sends metrics periodically to Datadog. By default, these metrics have k6. as the name prefix.

You can visualize k6 metrics in real-time with the metrics explorer, monitors, or custom dashboards.

To learn more about all the types of k6 metrics, read the k6 Metrics guide

The first time Datadog detects the k6.http_reqs metric, the k6 integration tile is installed automatically, and the default k6 dashboard is added to your dashboard list.

Optionally, you can install the k6 integration tile following these instructions:

Log in to Datadog.
From the sidebar menu, choose Integrations > Integrations.
Search for k6, then select the k6 integration.
Click on the Configuration tab option.
Scroll down and click on the Install integration button.

Dynatrace

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

Dynatrace

With the Dynatrace k6 extension, you can send visualize and correlate performance testing metrics with the other metrics that you monitor in Dynatrace.

Build the k6 version

To build a k6 binary with the extension, first, make sure you have Go and Git installed on your machine.

Then, open your terminal and run the following commands:

# Install xk6
go install go.k6.io/xk6/cmd/xk6@latest

# Build the k6 binary
xk6 build --with github.com/Dynatrace/xk6-output-dynatrace

... [INFO] Build environment ready
... [INFO] Building k6
... [INFO] Build complete: ./k6

xk6 will create the new k6 binary in the local folder.

Note
To learn more about how to build custom k6 versions, check out xk6.

Run the test

Create a Dynatrace API token to send the data.

Caution
The Dynatrace API Token must have the scope name “metrics.ingest” (scope type API v2).

You can use the Dynatrace UI:

Or a curl command (replace <environment-id> and the Api-Token):

curl -X POST "https://<environment-id>.live.dynatrace.com/api/v2/apiTokens" -H "accept: application/json; charset=utf-8" -H "Content-Type: application/json; charset=utf-8" -d "{\"name\":\"\",\"scopes\":[\"metrics.ingest\"]}" -H "Authorization: Api-Token XXXXXXXX"

Use the previously built k6 binary and run the test passing the Dynatrace URL and API token as follows:

# export dynatrace variables
export K6_DYNATRACE_URL=https://<environmentid>.live.dynatrace.com
export K6_DYNATRACE_APITOKEN=<Dynatrace API token>

# run the test
./k6 run script.js -o output-dynatrace

Check the metrics in your Dynatrace environment, filtering for k6:

Options

When streaming the k6 results to Dynatrace, you can configure the following Dynatrace options:

Name	Value
`K6_DYNATRACE_APITOKEN`	Dynatrace API token to write the metrics. The token must have the scope `metrics.ingest API v2`.
`K6_DYNATRACE_FLUSH_PERIOD`	Define how often metrics are sent to Dynatrace. The default value is 1 second.
`K6_DYNATRACE_URL`	Dynatrace URL. The default value is `https://dynatrace.live.com`.
`K6_DYNATRACE_INSECURE_SKIP_TLS_VERIFY`	If `true`, the HTTP client skips TLS verification on the endpoint. The default value is `true`.
`K6_DYNATRACE_HEADER_<here-the-header-key>`	Additional headers to include in the HTTP requests. `K6_DYNATRACE_HEADER_COOL_HEADER="cool value of the header"`

Elasticsearch

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

Elasticsearch

Using the Elasticsearch k6 extension, you can store k6 metrics in Elasticsearch and analyze your performance results with Kibana or Grafana.

Build the k6 version

To build a k6 binary with the extension, first, make sure you have Go and Git installed on your machine.

Then, open your terminal and run the following commands:

# Install xk6
go install go.k6.io/xk6/cmd/xk6@latest

# Build the k6 binary
xk6 build --with github.com/elastic/xk6-output-elasticsearch

... [INFO] Build environment ready
... [INFO] Building k6
... [INFO] Build complete: ./k6

xk6 will create the new k6 binary in the local folder.

Note
To learn more about how to build custom k6 versions, check out xk6.

Run the test

Check that the Elasticsearch instance to store the k6 metrics is running.

If you’re running on Elasticsearch cloud, use the previous k6 binary and run the test passing the cloud credentials as follows:

# export cloud configuration
export K6_ELASTICSEARCH_CLOUD_ID=your-cloud-id-here
export K6_ELASTICSEARCH_USER=your-user-here
export K6_ELASTICSEARCH_PASSWORD=your-password-here

# run the test
./k6 run script.js -o output-elasticsearch

k6 runs the test script and sends the metrics in real-time to Elasticsearch.

You can also send the metrics to a local Elasticsearch cluster:

# export local url
export K6_ELASTICSEARCH_URL=http://localhost:9200

# run the test
./k6 run script.js -o output-elasticsearch

Caution
Security and self-signed certificates for non-cloud clusters are not yet supported.

You can now connect to Elasticsearch and query the k6 metrics stored in the k6-metrics index. The following example uses an unsecured local Elasticsearch, version 7.17.9:

curl -XGET 'http://localhost:9200/k6-metrics/_search?pretty' -H 'Content-Type: application/json' -d'
{
  "sort": [
    {
      "Time": {
        "order": "desc"
      }
    }
  ],
  "size": 10
}'

Or use Kibana Discover:

Options

Here is the full list of options that can be configured and passed to the extension:

Name	Value
`K6_ELASTICSEARCH_CLOUD_ID`	Elasticsearch `cloud.id`, which can be found in the Elastic Cloud web console.
`K6_ELASTICSEARCH_FLUSH_PERIOD`	Define how often metrics are sent to Elasticsearch. The default value is 1 second.
`K6_ELASTICSEARCH_URL`	Elasticsearch URL.
`K6_ELASTICSEARCH_USER`	Elasticsearch username.
`K6_ELASTICSEARCH_PASSWORD`	Elasticsearch password.

Grafana Cloud k6

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

Grafana Cloud k6

Besides running cloud tests, you can also run a test locally and stream the results to Grafana Cloud k6.

When streaming the results to the cloud, the machine - where you execute the k6 CLI command - runs the test and uploads the results to the cloud-based solution. Then, you will be able to visualize and analyze the results on the web app in real-time.

Streaming results vs. running on cloud servers

Don’t confuse k6 cloud run --local-execution script.js (what this page is about) with k6 cloud run script.js.

Fundamentally the difference is the machine that the test runs on:

k6 cloud run --local-execution runs k6 locally and streams the results to the cloud.
k6 cloud run, on the other hand, uploads your script to the cloud solution and runs the test on the cloud infrastructure. In this case you’ll only see status updates in your CLI.

In all cases you’ll be able to see your test results at k6 Cloud or Grafana Cloud.

Caution
Data storage and processing are primary cloud costs, so k6 cloud run --local-execution will consume VUH or test runs from your subscription.

Instructions

Log in to the cloud

Assuming you have installed k6, the first step is to log in to the cloud service.

Run k6 cloud login — it will prompt you interactively for your API token and stack:
Bash
Bash
k6 cloud login
For non-interactive environments such as CI/CD, pass the values directly:
Bash
```
k6 cloud login --token <YOUR_API_TOKEN> --stack <YOUR_STACK_SLUG>
```
Run the tests and upload the results

Now, k6 will authenticate you against the cloud service, and you can use the --local-execution option to send the k6 results to the cloud as:
Bash
```
k6 cloud run --local-execution script.js
```
Alternatively, you could skip the k6 cloud login command when passing your API token and stack ID (available in your settings, along with your API token) to the k6 cloud run command as:
Bash
```
K6_CLOUD_TOKEN=<YOUR_API_TOKEN> K6_CLOUD_STACK_ID=<YOUR_STACK_ID> k6 cloud run --local-execution script.js
```
After running the command, the console shows a URL. Copy this URL and paste it in your browser’s address bar to visualize the test results.
Bash
```
execution: local
    output: cloud (https://acmecorp.grafana.net/a/k6-app/runs/123456)
    script: script.js
```

When you send the results to the k6 Cloud with k6 cloud run --local-execution, data will be continuously streamed to the cloud. While this happens the state of the test run will be marked as Running. A test run that ran its course will be marked Finished. The run state has nothing to do with the test passing any thresholds, only that the test itself is operating correctly.

If you deliberately abort your test (e.g. by pressing Ctrl-C), your test will end up as Aborted by User. You can still look and analyze the test data you streamed so far. The test will just have run shorter than originally planned.

Another possibility would be if you lose network connection with the cloud service while your test is running. In that case the cloud service will patiently wait for you to reconnect. In the meanwhile your test’s run state will continue to appear as Running on the web app.

If no reconnection happens, the cloud service will time out after two minutes of no data, setting the run state to Timed out. You can still analyze a timed out test but you’ll of course only have access to as much data as was streamed before the network issue.

Caution
The k6 cloud run --local-execution script.js command uploads the test archive k6 produces from your test script and resources to Grafana Cloud.

This behavior can be deactivated by adding the --no-archive-upload option to your command: k6 cloud run --local-execution --no-archive-upload script.js.

Stream logs to the cloud

Starting in k6 v2.2.0, k6 cloud run --local-execution also streams k6’s logs to Grafana Cloud k6. You can view them in the test run alongside the results, the same as a test that runs on cloud servers. Your local log output is unaffected.

To stop streaming logs to the cloud, pass --no-cloud-logs:

k6 cloud run --local-execution --no-cloud-logs script.js

Grafana Cloud Prometheus

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

Grafana Cloud Prometheus

Caution
This page includes instructions for running a local test that sends the test results to a Prometheus instance in Grafana Cloud.

For running and managing cloud tests in Grafana Cloud, check out Grafana Cloud k6.

You can send your k6 results to a Prometheus instance running in Grafana Cloud for visualization and analysis. By bringing k6 metrics into Grafana, you can correlate them with other observability metrics.

While this topic uses Grafana Cloud as an example, this approach is compatible with any remote write capable Prometheus installation.

Set up Grafana Cloud Prometheus

Before you start, you need the following:

A Grafana Cloud account (sign up). The free plan includes 10,000 Prometheus series.
The URL, username, and password of your Grafana Cloud Prometheus instance to configure the integration.

After you’ve set up your account, follow these steps:

Log in to Grafana.com and visit the Cloud Portal. Select the Details of your Prometheus service.
Copy the URL of the Remote Write Endpoint, along with the Username and Instance ID.
In the Password / API Token section, create and copy a Grafana Cloud Access Policy Token with the metrics:write scope (permission). The token will be used as a password.

Run the test

Now, pass the Username, Access Policy Token, and Remote Write Endpoint of the Grafana Cloud Prometheus Configuration to the k6 binary:

K6_PROMETHEUS_RW_USERNAME=USERNAME \
K6_PROMETHEUS_RW_PASSWORD=ACCESS_POLICY_API_TOKEN \
K6_PROMETHEUS_RW_SERVER_URL=REMOTE_WRITE_ENDPOINT \
k6 run -o experimental-prometheus-rw script.js

Visualize test results

To visualize test results with Grafana, you can import the k6 Prometheus dashboard by Grafana k6.

On the Dashboards UI:

Click New and select Import.
Paste the Grafana URL or ID of the dashboard, and click Load.
Select the Prometheus data source, and click Import.

Optionally, when running the test, you can set the testid tag as a wide test tag to filter results of a particular test run on this dashboard (or in PromQL queries). testid can be any unique string that allows you to identify the test run.

K6_PROMETHEUS_RW_USERNAME=USERNAME \
K6_PROMETHEUS_RW_PASSWORD=ACCESS_POLICY_API_TOKEN \
K6_PROMETHEUS_RW_SERVER_URL=REMOTE_WRITE_ENDPOINT \
k6 run -o experimental-prometheus-rw --tag testid=TEST_ID script.js

Additionally, you can also use the Explore UI to query k6 time series, design your visualization panels, and add them to any of your existing dashboards.

All the k6 time series have a k6_ prefix. For more details, refer to the documentation on the mapping of k6 metrics with Prometheus metrics.

It’s also important to understand the default Trend metric conversion process and the format and querying limitations. The K6_PROMETHEUS_RW_TREND_STATS option allows you to convert trend metrics to multiple Prometheus time series. For instance, K6_PROMETHEUS_RW_TREND_STATS=p(95),p(99),max,min transforms each k6 trend metric into four Prometheus metrics as follows:

k6_*_p95
k6_*_p99
k6_*_max
k6_*_min

InfluxDB

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

InfluxDB

k6 supports sending output metrics to InfluxDB v1.0 and v2.0.

Send k6 metrics to InfluxDB v1.0

k6 has built-in support to send metrics to InfluxDB v1.0.

You can use the --out flag with the influxdb option:

k6 run --out influxdb=http://localhost:8086/myk6db script.js

The example command makes k6 connect to a local InfluxDB instance and send the results from the test to a database named myk6db. If the database doesn’t exist, k6 creates one automatically.

Use a URL path prefix

A reverse proxy can expose several InfluxDB instances under one hostname, using a different path prefix for each instance. Include that prefix before the database name to send metrics to the correct instance with the built-in InfluxDB v1 output:

k6 run --out influxdb=https://influxdb.example.com/influxdb/myk6db script.js

Replace https://influxdb.example.com/influxdb with your InfluxDB address and path prefix, myk6db with your database name, and script.js with your test script.

k6 uses the final URL path segment as the database name and preserves the preceding path as the address prefix. In this example, k6 sends metrics to /influxdb/write for the myk6db database.

A trailing slash means that the entire path is the prefix and the URL does not specify a database name. For example, https://influxdb.example.com/influxdb/ uses /influxdb as the prefix and keeps the database configured through other options, or the default k6 database.

Send k6 metrics to InfluxDB v2.0

Using the InfluxDB extension, you can store k6 metrics in InfluxDB v2.0 and analyze your performance results with Grafana or other tools.

Build the k6 version

To build a k6 binary with the extension, first, make sure you have Go and Git installed on your machine.

Then, open your terminal and run the following commands:

# Install xk6
go install go.k6.io/xk6/cmd/xk6@latest

# Build the k6 binary
xk6 build --with github.com/grafana/xk6-output-influxdb

... [INFO] Build environment ready
... [INFO] Building k6
... [INFO] Build complete: ./k6

xk6 will create the new k6 binary in the local folder.

Note
To learn more about how to build custom k6 versions, check out xk6.

Run the test

Check that the InfluxDB instance to store the k6 metrics is running.

Use the previous k6 binary and run the test passing the following options:

K6_INFLUXDB_ORGANIZATION="<INFLUXDB-ORGANIZATION-NAME>" \
K6_INFLUXDB_BUCKET="<INFLUXDB-BUCKET-NAME>" \
K6_INFLUXDB_TOKEN="<INFLUXDB-TOKEN>" \
K6_INFLUXDB_ADDR="<INFLUXDB-HTTP-ADDRESS>" \
./k6 run script.js -o xk6-influxdb

k6 runs the test script and sends the k6 metrics in real-time to the InfluxDB instance. You can now select the bucket to query and visualize the stored k6 metrics, for example, using the InfluxDB Data Explorer.

Options

Here is the full list of options that can be configured and passed to the extension:

ENV	Default	Description
K6_INFLUXDB_ORGANIZATION		Your InfluxDB organization name. View organizations.
K6_INFLUXDB_BUCKET		The bucket name to store k6 metrics data. Manage buckets.
K6_INFLUXDB_TOKEN		An API token that provides authorized access to store data. Manage API tokens.
K6_INFLUXDB_ADDR	http://localhost:8086	The address of the InfluxDB instance.
K6_INFLUXDB_PUSH_INTERVAL	1s	The flush’s frequency of the `k6` metrics.
K6_INFLUXDB_CONCURRENT_WRITES	4	Number of concurrent requests for flushing data. It is useful when a request takes more than the expected time (more than flush interval).
K6_INFLUXDB_TAGS_AS_FIELDS	vu:int,iter:int,url	A comma-separated string to set `k6` metrics as non-indexable fields (instead of tags). An optional type can be specified using :type as in vu:int will make the field integer. The possible field types are int, bool, float and string, which is the default. Example: vu:int,iter:int,url:string,event_time:int.
K6_INFLUXDB_INSECURE	false	When `true`, it will skip `https` certificate verification.
K6_INFLUXDB_PRECISION	1ns	The timestamp Precision.
K6_INFLUXDB_HTTP_PROXY		Sets an HTTP proxy for the InfluxDB output.

Grafana Dashboards

You can use Grafana to query and visualize data from an InfluxDB instance. The instructions are available on InfluxDB and Grafana.

You can also build a custom Grafana dashboard to visualize the testing results in your own way.

For testing purposes, the InfluxDB extension repository includes a docker-compose setup with two basic dashboards.

JSON

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

JSON

You can output granular data points in JSON format. To do so, use k6 run with the --out flag. Pass the path for your JSON file as the flag argument:

k6 run --out json=test_results.json script.js

docker run -it --rm \
    -v <scriptdir>:/scripts \
    -v <outputdir>:/jsonoutput \
    grafana/k6 run --out json=/jsonoutput/my_test_result.json /scripts/script.js

# Note that the docker user must have permission to write to <outputdir>!

Or if you want to get the result gzipped, like this:

k6 run --out json=test_results.gz script.js

docker run -it --rm \
    -v <scriptdir>:/scripts \
    -v <outputdir>:/jsonoutput \
    grafana/k6 run --out json=/jsonoutput/my_test_result.gz /scripts/script.js

# Note that the docker user must have permission to write to <outputdir>!

To inspect the output in real time, you can use a command like tail -f on the file you save:

tail -f test_results.json

JSON format

The JSON output has lines as follows:

{"type":"Metric","data":{"type":"gauge","contains":"default","tainted":null,"thresholds":[],"submetrics":null},"metric":"vus"}
{"type":"Point","data":{"time":"2017-05-09T14:34:45.625742514+02:00","value":5,"tags":null},"metric":"vus"}
{"type":"Metric","data":{"type":"trend","contains":"time","tainted":null,"thresholds":["avg<1000"],"submetrics":null},"metric":"http_req_duration"}
{"type":"Point","data":{"time":"2017-05-09T14:34:45.239531499+02:00","value":459.865729,"tags":{"group":"::my group::json","method":"GET","status":"200","url":"https://quickpizza.grafana.com/api/tools"}},"metric":"http_req_duration"}

Each line either has information about a metric, or logs a data point (sample) for a metric. Lines consist of three items:

type - can have the values Metric or Point where Metric means the line is declaring a metric, and Point is an actual data point (sample) for a metric.
data - is a dictionary that contains lots of stuff, varying depending on the "type" above.
metric - the name of the metric.

Metric

This line has metadata about a metric. Here, "data" contains the following:

"type" - the metric type (“gauge”, “rate”, “counter” or “trend”)
"contains" - information on the type of data collected (can e.g. be “time” for timing metrics)
"tainted" - has this metric caused a threshold to fail?
"threshold" - are there any thresholds attached to this metric?
"submetrics" - any derived metrics created as a result of adding a threshold using tags.

Point

This line has actual data samples. Here, "data" contains these fields:

"time" - timestamp when the sample was collected
"value" - the actual data sample; time values are in milliseconds
"tags" - dictionary with tagname-tagvalue pairs that can be used when filtering results data

Processing JSON output

You can use jq to process the k6 JSON output.

You can quickly create filters to return a particular metric of the JSON file:

jq '. | select(.type=="Point" and .metric == "http_req_duration" and .data.tags.status >= "200")' myscript-output.json

And calculate an aggregated value of any metric:

jq '. | select(.type=="Point" and .metric == "http_req_duration" and .data.tags.status >= "200") | .data.value' myscript-output.json | jq -s 'add/length'

jq '. | select(.type=="Point" and .metric == "http_req_duration" and .data.tags.status >= "200") | .data.value' myscript-output.json | jq -s min

jq '. | select(.type=="Point" and .metric == "http_req_duration" and .data.tags.status >= "200") | .data.value' myscript-output.json | jq -s max

For more advanced cases, check out the jq Manual

Summary export

If you want to see only the aggregated data, you can export the end-of-test summary to a JSON file. For more details, refer to the handleSummary() topic in the end-of-test summary docs.

Metrics

Netdata

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

Netdata

Note
The built-in StatsD output has been deprecated on k6 v0.47.0 and removed in v0.55.0. You can continue to stream metrics to StatsD by using the xk6-output-statsd extension, or using the OpenTelemetry output depending on your use case.

For more information on the reason behind this change, you can follow this issue in the k6 repository.

k6 can send performance testing metrics to Netdata. This enables the user to start monitoring their k6 experiments right away, as Netdata is a monitoring tool with:

Auto-configuration and auto-detection of data sources
Automatic organization of metrics into meaningful charts and visualization
Per-second metric granularity

Before you begin

To use the StatsD output option, you have to build a k6 binary using the xk6-output-statsd extension. For more details, refer to StatsD.

Run Netdata

Netdata runs on many different systems and platforms. The easiest way to download and run Netdata is through the kickstart script:

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Alternatively, you can read more about installing and running Netdata in their documentation.

Setup Netdata for K6

Netdata runs a fully functional StatsD server by default and we have included a default configuration file for k6 metrics.

Run the k6 test

k6 run --out output-statsd script.js

Make sure you’re using the k6 binary you built with the xk6-output-statsd extension.

Caveat: By default, Netdata binds the StatsD server to localhost. That means that if Netdata and k6 are in different hosts, you will need to edit the configuration file of Netdata.

Visit the StatsD documentation for a reference on the configuration options. We are interested in the #bind to option.
Use sudo ./edit-config netdata.conf from inside the directory where Netdata stores its configuration files (e.g /etc/netdata/) and add bind to=udp:0.0.0.0:8125.

Visualize in Netdata

Netdata will automatically create charts for your application, as illustrated in the documentation.

Simply head over to localhost:19999 (assuming that you are running Netdata on the same machine) and find the k6 section. If you had opened Netdata before running the experiment, you will need to refresh the dashboard page.

New Relic

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

New Relic

Note
The built-in StatsD output has been deprecated on k6 v0.47.0 and removed in v0.55.0. You can continue to stream metrics to StatsD by using the xk6-output-statsd extension, or using the OpenTelemetry output depending on your use case.

For more information on the reason behind this change, you can follow this issue in the k6 repository.

k6 can send telemetry data to New Relic through the New Relic StatsD integration. Within New Relic you can find your k6 performance data alongside your real users data and server side performance. This data can be visualized in dashboards and shared with others, used to compare load impact with system performance, and alert on metrics too.

This guide covers running the New Relic integration:

Run the New Relic StatsD integration
Run the k6 test
Visualize k6 telemetry in New Relic

Before you begin

To use the StatsD output option, you have to build a k6 binary using the xk6-output-statsd extension. For more details, refer to StatsD.

Run the New Relic StatsD integration

To get k6 metrics into New Relic, k6 sends metrics to the New Relic StatsD integration which will take care of collecting, aggregate, format and send the telemetry to the New Relic Telemetry Data Platform. You can run this with or without a New Relic agent.

Run the New Relic integration as a Docker container with this command:

docker run --rm \
  -d \
  --name newrelic-statsd \
  -h $(hostname) \
  -e NR_ACCOUNT_ID=<NR-ACCOUNT-ID> \
  -e NR_API_KEY="<NR-INSERT-API-KEY>" \
  -p 8125:8125/udp \
  newrelic/nri-statsd:latest

Replace <NR-ACCOUNT-ID> with your New Relic Account ID and <NR-INSERT-API-KEY> with your New Relic Insert API Key.

If your account is hosted in the New Relic EU region, then also add this to the above command: -e NR_EU_REGION=true \

The required environment variables used in the above command are:

Name	Value
`NR_ACCOUNT_ID`	The Account ID used in New Relic You can find your account ID here.
`NR_API_KEY`	The Insert API Key for your New Relic account to send k6 telemetry to the account ID specified above. You can generate an Insert API key here.

Optional environment variables you can use:

Name	Value
`NR_EU_REGION`	Setting this to `true` tells the integration your account is housed in the New Relic EU region.
`TAGS`	Setting tags in key:value format separated by a space lets you further understand your data in New Relic. For example identifying different test runs or machines running the tests. In the docker command add: `-e TAGS="k6Test:myExampleTest someKey:someValue" \`.
`NR_LOG_METRICS`	Setting this to `true` activates verbose logging for the integration.

About the New Relic integration

The New Relic StatsD integration installed above can run standalone. Installing a New Relic agent is optional.

Everything provided in the command above is enough to send k6 performance metrics to New Relic. You can optionally however add further configuration, further define metrics and their formats (you can however do this on the New Relic side configuration), add custom tags, and create alerts. This is covered in the optional table below.

Run the k6 test

Once the integration is running, run the k6 test and send the metrics to the integration with:

K6_STATSD_ENABLE_TAGS=true k6 run --out output-statsd script.js

Make sure you’re using the k6 binary you built with the xk6-output-statsd extension.

You can look at the StatsD output page for configuration options.

Visualisation in New Relic

As your k6 test is running, k6 is sending performance metrics to the New Relic StatsD integration which in turn is sending these metrics to the New Relic Telemetry Data Platform. These will be prefixed with k6. so you can identify them.

You can visualize the metrics sent from this integration in the data explorer in the top right of New Relic (query your data).

You can also add these metrics to dashboards and alert on k6 metrics.

Example NRQL Queries

Note
New Relic doesn’t support calculating percentiles from metric data, which is the data format sent by this k6 output. See this New Relic forum post and the documentation about the metric data type for details.

Here are some example NRQL queries you can easily copy and paste into widgets in a New Relic dashboard, you can however stick with the chart builder. Find all your k6 Metrics under the metrics tab, prefixed with k6.

Number of Virtual Users

SELECT latest(k6.vus) FROM Metric TIMESERIES

Max, Median, and Average Request Duration

SELECT max(k6.http_req_duration.summary) AS 'Max Duration', average(k6.http_req_duration.median) AS 'Median', average(k6.http_req_duration.mean) AS 'Avg' FROM Metric TIMESERIES

Rate of Requests

SELECT rate(max(k6.http_reqs), 1 seconds) FROM Metric TIMESERIES

Data Sent and Data Received

SELECT sum(k6.data_received) as 'Data Received', max(k6.data_sent) AS 'Data Sent' FROM Metric TIMESERIES

Histogram bucketing Requests

SELECT histogram(`k6.http_reqs`, 80, 20) FROM Metric

Change in the number of Requests

SELECT derivative(k6.http_reqs, 30 seconds) AS 'Rate /reqs' FROM Metric TIMESERIES

Scrolling List of all k6 Performance Metrics

SELECT uniques(metricName) FROM Metric WHERE metricName LIKE 'k6%' LIMIT MAX

OpenTelemetry

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

OpenTelemetry

Grafana k6 can push test run metrics in the OpenTelemetry (OTEL) metrics format to an OTEL metrics collector or a metrics backend that supports the OTEL metrics format by using the OpenTelemetry output --out opentelemetry.

For any feedback, bugs or suggestions feel free to open an issue directly in the k6 repository. Contributions are also welcome!

Metrics mapping

k6 converts all k6 metric types to an equivalent OTEL metric type, and all k6 tags to OTEL attributes. When possible, the units are also passed with the metrics.

k6 Metric	OpenTelemetry Metric
Counter	`Float64CounterOption`
Gauge	`Float64ObservableGauge`
Rate	Exported as a single `Int64Counter` counter named `metric_name` with an attribute `condition` that can have two values: `zero` and `nonzero`. If you previously used the legacy pair-of-counters format (`metric_name.occurred` / `metric_name.total`), update your dashboards and queries to filter on the `condition` attribute instead.
Trend	`Float64Histogram`

Run the k6 test

You can use the --out opentelemetry option when running your tests to use this extension:

K6_OTEL_GRPC_EXPORTER_INSECURE=true K6_OTEL_METRIC_PREFIX=k6_ k6 run --tag test-id=123 -o opentelemetry examples/script.js

Configuration

The following options can be configured:

Name	Value
`K6_OTEL_SERVICE_NAME`	The name of the service to use for the metrics exporting. Default value is `k6`.
`K6_OTEL_SERVICE_VERSION`	The version of the service to use for the metrics exporting. Default is version of the k6, e.g. `v0.54.0`
`K6_OTEL_METRIC_PREFIX`	Metric prefix. Default is empty.
`K6_OTEL_FLUSH_INTERVAL`	How frequently to flush metrics from k6 metrics engine. Default is `1s`.
`K6_OTEL_EXPORT_INTERVAL`	Configures the intervening time between metrics exports. Default is `10s`.
`K6_OTEL_HEADERS`	Configures headers in the W3C Correlation-Context format without additional semi-colon delimited metadata (i.e. “k1=v1,k2=v2”). Passes the headers to the exporter.
`K6_OTEL_TLS_INSECURE_SKIP_VERIFY`	Disables server certificate verification.
`K6_OTEL_TLS_CERTIFICATE`	Configures the path to the root CA certificate file for TLS credentials. If it is not provided but TLS is enabled then the host’s root CAs set is used.
`K6_OTEL_TLS_CLIENT_CERTIFICATE`	Configures the path to the client certificate file.
`K6_OTEL_TLS_CLIENT_KEY`	Configures the path to the client key file.
`K6_OTEL_EXPORTER_PROTOCOL`	Configures the protocol of exporter to use. Valid options are `grpc` and `http/protobuf`. Default is `grpc`.
`K6_OTEL_GRPC_EXPORTER_INSECURE`	Disables client transport security for the gRPC exporter.
`K6_OTEL_GRPC_EXPORTER_ENDPOINT`	Configures the gRPC exporter endpoint. Default is `localhost:4317`.
`K6_OTEL_HTTP_EXPORTER_INSECURE`	Disables client transport security for the HTTP exporter.
`K6_OTEL_HTTP_EXPORTER_ENDPOINT`	Configures the HTTP exporter endpoint. Must be host and port only, without scheme. Default is `localhost:4318`.
`K6_OTEL_HTTP_EXPORTER_URL_PATH`	Configures the HTTP exporter path. Default is `/v1/metrics`.
`K6_OTEL_HTTP_EXPORTER_USERNAME`	Username for HTTP Basic authentication on the HTTP exporter.
`K6_OTEL_HTTP_EXPORTER_PASSWORD`	Password for HTTP Basic authentication on the HTTP exporter.

You can also use the OpenTelemetry SDK configuration environment variables to configure the OpenTelemetry output, like the gRPC exporter configuration. The K6_OTEL_* environment variables take precedence over the OpenTelemetry SDK configuration environment variables.

Prometheus remote write

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

Prometheus remote write

Caution
This is an experimental module.

While we intend to keep experimental modules as stable as possible, we may need to introduce breaking changes. This could happen at future k6 releases until the module becomes fully stable and graduates as a k6 core module. For more information, refer to the versioning and stability guarantees document.

Experimental modules maintain a high level of stability and follow regular maintenance and security measures. Feel free to open an issue if you have any feedback or suggestions.

Prometheus remote write is a protocol that makes it possible to reliably propagate data in real-time from a sender to a receiver. It has multiple compatible implementations and storage integrations.

For instance, when using the experimental-prometheus-rw output, k6 can send test-result metrics to the remote-write endpoint and store them in Prometheus.

The output, during the k6 run execution, gets all the generated time-series data points for the k6 metrics. It then generates the equivalent Prometheus time series and sends them to the Prometheus remote write endpoint.

Metrics mapping

All k6 metric types are converted into an equivalent Prometheus metric type. The output maps the metrics into time series with Name labels. As much as possible, k6 respects the naming best practices that the Prometheus project defines:

All time series are prefixed with the k6_ namespace.
All time series are suffixed with the base unit of the sample value (if k6 knows what the base unit is).
Trends and rates have the relative suffixes, to make them more discoverable.

k6	Prometheus	Name label
Counter	Counter	`k6_*_total`
Gauge	Gauge	`k6_*_<unit-suffix>`
Rate	Gauge	`k6_*_rate`
Trend	Counter and Gauges (default) or Native Histogram	`k6_*_<unit-suffix>`

Trend metric conversions

This output provides two distinct mechanisms to send k6 Trend metrics to Prometheus:

Counter and Gauge metrics (default)
Prometheus Native histogram

Both options provide efficient storage of test results while providing high-precision queries.

Note that k6 aggregates trend metric data before sending it to Prometheus in both options. The reasons for aggregating data are:

Prometheus stores data in a millisecond precision (ms), but k6 metrics collect data points with higher accuracy, nanosecond (ns).
A load test could generate vast amounts of data points. High-precision raw data could quickly become expensive and complex to scale and is unnecessary when analyzing performance trends.

1. Counter and gauges

By default, Prometheus supports Counter and Gauge Metric types. Therefore, this option is the default of this output and converts all the k6 Trend metrics to Counter and Gauges Prometheus metrics.

You can configure how to convert all the k6 trend metrics with the K6_PROMETHEUS_RW_TREND_STATS option that accepts a comma-separated list of stats functions: count, sum, min, max, avg, med, p(x). The default is p(99).

Given the list of stats functions, k6 converts all trend metrics to the respective math functions as Prometheus metrics.

For example, K6_PROMETHEUS_RW_TREND_STATS=p(90),p(95),max transforms each trend metric into three Prometheus metrics as follows:

k6_*_p90
k6_*_p95
k6_*_max

This option provides a configurable solution to represent Trend metrics in Prometheus but has the following drawbacks:

Convert a k6 Trend metric to several Prometheus metrics.
It is impossible to aggregate some gauge values (especially percentiles).
It uses a memory-expensive k6 data structure.

2. Prometheus native histogram

To address the limitations of the previous option, you can convert k6 trend metrics to high-fidelity histograms enabling Prometheus native histograms.

With this option, each k6 trend metric maps to its corresponding Prometheus histogram metric: k6_*. You can then query them using Prometheus histogram functions, such as histogram_quantile().

Note
🌟 To learn the benefits and outcomes of using Histograms, watch High-resolution Histograms in Prometheus.

⚠️ Note that Native Histogram is an experimental feature released in Prometheus v2.40.0, and other remote write implementations might not support it yet. In the future, when Prometheus makes this feature stable, k6 will consider using it as the default conversion method for Trend metrics.

Send test metrics to a remote write endpoint

To use remote write in Prometheus 2.x, enable the feature flag –web.enable-remote-write-receiver. For remote write storage options, refer to the Prometheus docs.

To send k6 metrics to a remote write endpoint without native histograms:

Set up a running remote write endpoint and ensure k6 can reach it.
Run your k6 script with the --out flag and the URL of the RW endpoint as follows:

Trend stats

K6_PROMETHEUS_RW_SERVER_URL=http://localhost:9090/api/v1/write \
k6 run -o experimental-prometheus-rw script.js

HTTP Basic Authentication

K6_PROMETHEUS_RW_SERVER_URL=http://localhost:9090/api/v1/write \
K6_PROMETHEUS_RW_USERNAME=USERNAME \
K6_PROMETHEUS_RW_PASSWORD=PASSWORD \
k6 run -o experimental-prometheus-rw script.js

Optionally, pass the K6_PROMETHEUS_RW_TREND_STATS to gain the ability to query additional stats for trend metrics. The default is p(99).

K6_PROMETHEUS_RW_SERVER_URL=http://localhost:9090/api/v1/write \
K6_PROMETHEUS_RW_TREND_STATS=p(95),p(99),min,max \
k6 run -o experimental-prometheus-rw script.js

To send k6 metrics to a remote write endpoint with native histograms:
- Enable the feature flag –enable-feature=native-histograms in Prometheus 2.40.0 or higher. Set up a running remote write endpoint and ensure k6 can reach it.
- Run your k6 script with the --out flag, enabling the K6_PROMETHEUS_RW_TREND_AS_NATIVE_HISTOGRAM option, and the URL of the RW endpoint as follows:
Native Histogram
Bash
```
K6_PROMETHEUS_RW_SERVER_URL=http://localhost:9090/api/v1/write \
K6_PROMETHEUS_RW_TREND_AS_NATIVE_HISTOGRAM=true \
k6 run -o experimental-prometheus-rw script.js
```
HTTP Basic Authentication
Bash
```
K6_PROMETHEUS_RW_SERVER_URL=http://localhost:9090/api/v1/write \
K6_PROMETHEUS_RW_TREND_AS_NATIVE_HISTOGRAM=true \
K6_PROMETHEUS_RW_USERNAME=USERNAME \
K6_PROMETHEUS_RW_PASSWORD=PASSWORD \
k6 run -o experimental-prometheus-rw script.js
```

When running the previous k6 run commands, k6 starts sending time-series metrics to Prometheus. All the time series have a k6_ prefix. In the Prometheus Web UI, they appear like this:

Options

k6 has special options for remote write output.

Name	Type	Description
`K6_PROMETHEUS_RW_SERVER_URL`	`string`	URL of the Prometheus remote write implementation’s endpoint. Default is `http://localhost:9090/api/v1/write`
`K6_PROMETHEUS_RW_HEADERS_<header-key>`	`string`	Additional header to include in the HTTP requests. It can be set using the described format, for example `K6_PROMETHEUS_RW_HEADERS_CUSTOM-HEADER-KEY=custom-header-value`.
`K6_PROMETHEUS_RW_HTTP_HEADERS`	A comma-separated list of key-values	Additional headers to include in the HTTP requests. `K6_PROMETHEUS_RW_HTTP_HEADERS=key1:value1,key2:value2`.
`K6_PROMETHEUS_RW_LABELS`	A comma-separated list of key-value pairs	Static labels to add to remote write time series, for example `environment=production,server=srv1`. No additional labels by default. Refer to Add static labels.
`K6_PROMETHEUS_RW_PUSH_INTERVAL`	`string`	Interval between the metrics’ aggregation and upload to the endpoint. Default is `5s`.
`K6_PROMETHEUS_RW_TREND_AS_NATIVE_HISTOGRAM`	`boolean`	If true, maps all the defined trend metrics as Native Histograms. Default is `false`.
`K6_PROMETHEUS_RW_TREND_STATS`	list of `string`	If Native Histogram is not enabled, then it defines the stats functions to map for all of the defined trend metrics. It’s a comma-separated list of stats functions to include (e.g. `p(90),avg,sum`). Check the trend section to see the list of supported stats. Default is `p(99)`.
`K6_PROMETHEUS_RW_INSECURE_SKIP_TLS_VERIFY`	`boolean`	If true, the HTTP client skips TLS verification on the endpoint. Default is `false`.
`K6_PROMETHEUS_RW_TLS_MIN_VERSION`	`string`	Sets the minimum TLS version used by the HTTP client. Available options: `1.2` and `1.3`. Default is `1.3`.
`K6_PROMETHEUS_RW_STALE_MARKERS`	`boolean`	If true, the output at the end of the test marks all the seen time series as stale. Default is `false`.
`K6_PROMETHEUS_RW_USERNAME`	`string`	Username for the HTTP Basic authentication at the Prometheus remote write endpoint.
`K6_PROMETHEUS_RW_PASSWORD`	`string`	Password for the HTTP Basic authentication at the Prometheus remote write endpoint.
`K6_PROMETHEUS_RW_CLIENT_CERTIFICATE`	`string`	A path to the PEM (Privacy-Enhanced Mail) formatted client certificate.
`K6_PROMETHEUS_RW_CLIENT_CERTIFICATE_KEY`	`string`	A path to the PEM formatted client private key.
`K6_PROMETHEUS_RW_BEARER_TOKEN`	`string`	Sets the Authorization Bearer Token Header.
`K6_PROMETHEUS_RW_SIGV4_REGION`	`string`	Sets the AWS region where the workspace is. Along with the others `K6_PROMETHEUS_RW_SIGV4_*` configurations enables signing requests.
`K6_PROMETHEUS_RW_SIGV4_ACCESS_KEY`	`string`	Sets the AWS access key.
`K6_PROMETHEUS_RW_SIGV4_SECRET_KEY`	`string`	Sets the AWS secret key.

Add static labels

When several k6 processes send metrics to the same Prometheus endpoint, use a label such as server or job_id to distinguish their time series. Set a different value for each process or job that you want to identify separately. This lets you configure labels in your deployment or CI job without changing the test script.

Set K6_PROMETHEUS_RW_LABELS to add static labels to every time series sent to the remote write endpoint. Use a comma-separated list of key=value pairs:

K6_PROMETHEUS_RW_LABELS="environment=production,server=srv1" \
k6 run -o experimental-prometheus-rw script.js

Replace script.js with your test script and configure your remote write endpoint as described in Send test metrics to a remote write endpoint.

You can also set collectors.experimental-prometheus-rw.labels in a JSON configuration file:

{
  "collectors": {
    "experimental-prometheus-rw": {
      "labels": {
        "environment": "production",
        "server": "srv1"
      }
    }
  }
}

Save this as config.json and run your test:

k6 run --config config.json -o experimental-prometheus-rw script.js

If you configure the same label in both places, K6_PROMETHEUS_RW_LABELS takes precedence over the JSON configuration.

These labels apply only to the remote write output. Existing time-series labels, including labels from script tags, take precedence over static labels with the same name. k6 ignores labels with an empty name or value, and ignores the reserved __name__ label.

Stale trend metrics

This k6 output can mark the time series at the end of the test as stale. To enable the stale marker option, set the K6_PROMETHEUS_RW_STALE_MARKERS environment variable to true.

By default, the metrics are active for 5 minutes after the last flushed sample. They are automatically marked as stale after. For details about staleness, refer to the Prometheus docs.

Time series visualization

To visualize time series with Grafana, you can use the Explore UI or import any of the existing pre-built dashboards:

If you are a Grafana Cloud user, please refer to the Grafana Cloud Prometheus docs.

For a local environment, the xk6-output-prometheus-remote repository includes a docker-compose setup that provisions the k6 Prometheus and k6 Prometheus (Native Histograms) dashboards:

Docker compose example

Clone the repository to get started and follow these steps for using the docker-compose.yml file that starts Prometheus and Grafana:

Start the docker compose environment.
shell
```
docker compose up -d prometheus grafana
```
shell
```
# Output
Creating xk6-output-prometheus-remote_grafana_1     ... done
Creating xk6-output-prometheus-remote_prometheus_1  ... done
```
Prometheus is started with Native Histogram enabled. You can use the same Prometheus instance to receive k6 trend metrics as native histograms or multiple metric stats.

Run the k6 test with one of the options detailed on Send test metrics to a remote write endpoint.

Trend stats

K6_PROMETHEUS_RW_TREND_STATS=p(95),p(99),min,max \
k6 run -o experimental-prometheus-rw script.js

Native Histograms

K6_PROMETHEUS_RW_TREND_AS_NATIVE_HISTOGRAM=true \
k6 run -o experimental-prometheus-rw script.js

Optionally, you can set the testid tag as a wide test tag to segment metrics into discrete test runs and filter specific test results on the pre-built Grafana dashboards or in PromQL queries. testid can be any unique string that let you clearly identify the test run.

Trend stats

K6_PROMETHEUS_RW_TREND_STATS=p(95),p(99),min,max \
k6 run -o experimental-prometheus-rw --tag testid=<SET-HERE-A-UNIQUE-ID> script.js

Native Histograms

K6_PROMETHEUS_RW_TREND_AS_NATIVE_HISTOGRAM=true \
k6 run -o experimental-prometheus-rw --tag testid=<SET-HERE-A-UNIQUE-ID> script.js

After running the test, visit http://localhost:3000. If you enabled native histograms, select the k6 Prometheus (Native Histograms) dashboard; otherwise, select the k6 Prometheus Dashboard.

StatsD

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

StatsD

Note
The built-in StatsD output has been deprecated on k6 v0.47.0 and removed in v0.55.0. You can continue to stream metrics to StatsD by using the xk6-output-statsd extension, or using the OpenTelemetry output depending on your use case.

For more information on the reason behind this change, you can follow this issue in the k6 repository.

k6 can push test metrics to a StatsD service by using the xk6-output-statsd extension.

Build the k6 version

To build a k6 binary with the extension, first, make sure you have Go and Git installed on your machine.

Then, open your terminal and run the following commands:

# Install xk6
go install go.k6.io/xk6/cmd/xk6@latest

# Build the k6 binary
xk6 build --with github.com/LeonAdato/xk6-output-statsd

... [INFO] Build environment ready
... [INFO] Building k6
... [INFO] Build complete: ./k6

xk6 will create the new k6 binary in the local folder.

Note
To learn more about how to build custom k6 versions, check out xk6.

Run the k6 test

Using the k6 binary you built in the previous step, you can use the --out output-statsd option when running your tests to use this extension:

./k6 run --out output-statsd script.js

The following options can be configured:

Name	Value
`K6_STATSD_ADDR`	Address of the statsd service, currently only UDP is supported. The default value is `localhost:8125`.
`K6_STATSD_NAMESPACE`	The namespace used as a prefix for all the metric names. The default value is `k6`.
`K6_STATSD_PUSH_INTERVAL`	Configure how often data batches are sent. The default value is `1s`.
`K6_STATSD_BUFFER_SIZE`	The buffer size. The default value is `20`.
`K6_STATSD_ENABLE_TAGS`	If `true` enables sending tags. `false` by default as old versions of statsd, prior to v0.9.0 did not support tags.
`K6_STATSD_TAG_BLOCKLIST`	This is a comma-separated list of tags that should NOT be sent to statsd. For example, “tag1,tag2”. The default value is `vu,iter,url`.

TimescaleDB

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

TimescaleDB

Using the TimescaleDB k6 extension, you can store k6 metrics in TimescaleDB and analyze your performance results with SQL and dashboards. The extension repository includes two Grafana dashboards.

Build the k6 version

To build a k6 binary with the extension, first, make sure you have Go and Git installed on your machine.

Then, open your terminal and run the following commands:

# Install xk6
go install go.k6.io/xk6/cmd/xk6@latest

# Build the k6 binary
xk6 build --with github.com/grafana/xk6-output-timescaledb

... [INFO] Build environment ready
... [INFO] Building k6
... [INFO] Build complete: ./k6

xk6 will create the new k6 binary in the local folder.

Note
To learn more about how to build custom k6 versions, check out xk6.

Run the test

Check that the TimescaleDB instance is running. Copy the Postgres connection string of the database, which will store the k6 metrics.

Use the previous k6 binary and run the test passing the Postgres connection string to the output option as follows:

k6 run script.js -o timescaledb=postgresql://<postgresql_user_name>:<password>@<ip>:<port>/<database>

k6 runs the test script and sends the metrics in real-time to the TimescaleDB instance. You can now connect to TimescaleDB and query the k6 metrics.

k6=# SELECT metric,AVG (value) FROM samples GROUP BY metric;

Options

Here is the full list of options that can be configured and passed to the extension:

Name	Value
`K6_TIMESCALEDB_PUSH_INTERVAL`	Define how often metrics are sent to TimescaleDB. The default value is 1s (1 second).

Grafana Dashboards

The extension repository includes a docker-compose setup with two pre-built dashboards to:

list test runs
visualize the results of a test run

Store k6 metrics in TimescaleDB and visualize with Grafana

Real time on Grafana Labs

Amazon CloudWatch

Amazon CloudWatch

Before you begin

Run the CloudWatch agent

Run the k6 test

Visualize k6 metrics in Amazon CloudWatch

Apache Kafka

Apache Kafka

Build the k6 version

Run the k6 test

Options

Read more

CSV

CSV

CSV format

CSV options

Read more

Datadog

Datadog

Before you begin

Run the Datadog Agent

DogStatsD

Run the k6 test

Visualize in Datadog

Dynatrace

Dynatrace

Build the k6 version

Run the test

Options

Elasticsearch

Elasticsearch

Build the k6 version

Run the test

Options

Grafana Cloud k6

Grafana Cloud k6

Streaming results vs. running on cloud servers

Instructions

Stream logs to the cloud

Grafana Cloud Prometheus

Grafana Cloud Prometheus

Set up Grafana Cloud Prometheus

Run the test

Visualize test results

InfluxDB

InfluxDB

Send k6 metrics to InfluxDB v1.0

Use a URL path prefix

Send k6 metrics to InfluxDB v2.0

Build the k6 version

Run the test

Options

Grafana Dashboards

JSON

JSON

JSON format

Metric

Point

Processing JSON output

Summary export

Read more

Netdata

Netdata

Before you begin

Run Netdata

Setup Netdata for K6

Run the k6 test

Visualize in Netdata

New Relic

New Relic

Before you begin

Run the New Relic StatsD integration

About the New Relic integration

Run the k6 test

Visualisation in New Relic

Example NRQL Queries

OpenTelemetry

OpenTelemetry

Metrics mapping