Reference on Grafana Labs

Integrations & Tools

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

Integrations & Tools

Test authoring

Codeless tools to speed up the test creation.

Test Builder - Inspired by the Postman API Builder. Codeless UI tool to generate a k6 test quickly.

AI assistants (MCP)

MCP (Model Context Protocol) integrations help you author and run k6 scripts from MCP-compatible editors and assistants.

To validate and run scripts, browse documentation, and generate tests using an AI assistant, refer to Configure your AI assistant.
To scaffold k6 skills and auto-register the k6 MCP server in supported editors with one command, refer to Bootstrap your editor with k6 x agent.

IDE extensions

Code k6 scripts in your IDE of choice. Empower your development workflow with IDE extensions.

Visual Studio Code Extension - Run k6 tests from VS Code.
IntelliJ IDEA - Run k6 tests from IntelliJ IDEs.
IntelliSense - Get code autocompletion and in-context documentation.

Converters

Generate a k6 script quickly from an existing file.

HAR-to-k6 - Convert a HAR file to a k6 script.
Postman-to-k6 - Convert a Postman collection to a k6 script.
OpenAPI generator - Convert a Swagger/OpenAPI specification to a k6 script.

Result store and visualization

k6 can output test results to various formats and 3rd-party services.

Continuous Integration and Continuous Delivery

By automating load testing with your CI / CD tools, you can quickly see when a code change has introduced a performance regression.

Chaos engineering

Steadybit - Using k6 and Steadybit for chaos engineering.
xk6-disruptor - A k6 extension for injecting faults into k6 tests.
ChaosToolkit - A collection of k6 actions and probes.
LitmusChaos - Simulate load generation to the target application as a part of chaos testing on Kubernetes using Litmus.

Test management

Azure Test Plan - k6 load testing with Azure DevOps.
TestRail - Introducing TestRail in your k6 tests.
Testkube - Load testing with Testkube.
Tracetest - Trace-based testing with Tracetest.
Xray - Using Xray to validate test results in JIRA.

Reach out to us if you have a tool or add-on that works well with k6, and we will list it here!

Archive Command

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

Archive Command

What is an archive?

When the complexity of a k6 test goes beyond a single JS file it quickly becomes cumbersome to find and bundle up all the dependencies (JS, open()’ed data files, TLS client certs, etc.). k6 archives are a native way to bundle and distribute, or share, a test.

A k6 archive is simply a tar file with all files needed to execute a k6 test.

How to create and run an archive

Let’s say that you normally execute a test using:

k6 run script.js

Now if you replace run with archive k6 will run the init stage of the code to determine which JS files are being imported and what data files are being open()’ed and bundles all of the files up into a tar file:

k6 archive script.js

This would produce a tar file on disk called archive.tar (you can change that by setting -O filename.tar). It’s also easy to run an archive, as k6 run is compatible with archive files you can execute:

⚠️ Overriding options

As always you can override options using CLI flags or environment variables when running an archive.

k6 run archive.tar

Use cases

Archive files have a variety of use cases, but they all share the common need to bundle of a test’s files into a single file for easy distribution.

By bundling up a test into an archive it’s easy to share the test with your teammates by simply storing or sending a single tar file. As we saw in the previous section, your teammates can execute the archive by running k6 run archive.tar.

Preparing tests for CI

If you have a complex CI pipeline and your load tests are separated from your application code, you could store k6 archives as build artifacts whenever the load test source code is changed, and then pull in those k6 archives from the artifacts storage for test execution as needed.

k6 Cloud Execution

k6 offers a commercial service for running large scale and geographically distributed load tests on managed cloud infrastructure. Cloud executed tests are triggered from the k6 command-line via the k6 cloud run script.js command (similar to k6 run) which will trigger an implicit creation of a k6 archive that is uploaded and distributed to k6 cloud load generators for execution.

Uploading an archive to k6 Cloud

Under certain scenarios, such as scheduled executions, users might want to upload an archive to k6 Cloud without triggering a test execution in the process.

To cater to this use case, the k6 cloud upload command was introduced. This command allows users to upload an archive to k6 Cloud without triggering a test execution. The command syntax is as follows:

k6 cloud upload archive.tar

Distributed Execution

k6-operator can distribute a k6 test across a Kubernetes cluster.

When a k6 test has multiple files, you can use the archive functionality to bundle the k6 test in a single archived file and pass this file to run the test.

Contents of an archive file

An archive contains the original source of the JS code, any open()’ed data files, SSL/TLS client certificates as well as a metadata.json with all the options (a cascading of the options set on the CLI, via Environment variables and in-script options (export let options = {...})).

Let’s create an archive from the following sample test. Here is the layout in the filesystem of the files:

/home/johndoe/tests/api-test $ tree
.
├── utils
|   └-- common.js
├── endpoints
|   ├── login.js
|   └-- search.js
├── node_modules
|   └-- somelib
|       └-- lib.js
├── data
|   └-- users.json
└-- script.js

Now, if the current working directory is /home/johndoe/tests/api-test/ and we run k6 archive script.js we’d get a tar file called archive.tar (you can change the name of the file using -O filename.tar). The contents of the archive file would look like something like this:

├-- data
├-- files
|   └-- home
|       └-- nobody <-- the username has been anonymized (see section further down)
|           └-- tests
|               └-- api-test
|                   └-- data
|                       └-- users.json
├-- metadata.json
└-- scripts
    └-- home
        └-- nobody <-- the username has been anonymized (see section further down)
            └-- tests
                └-- api-test
                    ├-- script.js
                    ├-- utils
                    |   └-- common.js
                    ├-- endpoints
                    |   ├-- login.js
                    |   └-- search.js
                    └-- node_modules
                        └-- somelib
                            └-- lib.js

Breaking down the file structure we get:

data contains the source code of the main JS file (script.js in this example).

files contains the full original directory tree of all open()’ed data files.

metadata.json The resolved “default” options for this test based on CLI flags, Environment variables and in-script options.

scripts contains the full original directory tree of all import‘ed JS dependencies.

{
  "type": "js",
  "options": {
    "paused": null,
    "vus": null,
    "duration": null,
    "iterations": null,
    "stages": null,
    "setupTimeout": null,
    "teardownTimeout": null,
    "rps": null,
    "maxRedirects": null,
    "userAgent": null,
    "batch": null,
    "batchPerHost": null,
    "httpDebug": null,
    "insecureSkipTLSVerify": null,
    "tlsCipherSuites": null,
    "tlsVersion": {
      "min": "",
      "max": ""
    },
    "tlsAuth": null,
    "throw": null,
    "thresholds": null,
    "blacklistIPs": null,
    "hosts": null,
    "noConnectionReuse": null,
    "ext": null,
    "summaryTrendStats": null,
    "systemTags": [
      "url",
      "name",
      "check",
      "error",
      "tls_version",
      "method",
      "subproto",
      "status",
      "group",
      "proto"
    ],
    "tags": null
  },
  "filename": "/home/johndoe/tests/api-test/script.js",
  "pwd": "/home/johndoe/tests/api-test/",
  "env": {}
}

What an archive file does not contain

We try to be cautious with what we include in an archive file. Some things we do to that end:

We anonymize the username found in any path to JS and data file dependencies
By default, k6 omits environment variables from the system in the archive. However, if you use the flag --include-system-env-vars, k6 includes the environment variables in the archive (along with any variables passed with --env). To avoid including system environment variables in the archive, you can use the k6 archive flag --exclude-env-vars.

Cloud commands

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

Cloud commands

The k6 cloud command and its subcommands run and manage tests in Grafana Cloud k6 from the command line. Use them to authenticate, run or upload tests, and inspect the projects, tests, and load zones available in your stack.

Authentication

Every k6 cloud subcommand requires an API token and a configured stack. Authenticate once with k6 cloud login, or set the K6_CLOUD_TOKEN and K6_CLOUD_STACK_ID environment variables:

K6_CLOUD_TOKEN=<YOUR_API_TOKEN> K6_CLOUD_STACK_ID=<YOUR_STACK_ID> k6 cloud run script.js

For instructions on how to generate a token, refer to Tokens and CLI authentication.

Authenticate with Grafana Cloud k6 and save the token and stack to the k6 configuration file so that later k6 cloud commands can reuse them. Run it without flags to be prompted interactively for your token and stack:

k6 cloud login

You can also pass the values directly, where the stack is a full URL or a slug:

k6 cloud login --token <YOUR_API_TOKEN> --stack <YOUR_STACK_URL_OR_SLUG>

Option	Description
`-t`, `--token`	The API token to authenticate with.
`--stack`	The stack (URL or slug) where commands run by default.
`-s`, `--show`	Display the saved token and stack information, then exit.
`-r`, `--reset`	Reset the stored token and stack information.

For the full cloud testing workflow, refer to Run a k6 test script.

k6 cloud run

Run a test in Grafana Cloud k6. k6 builds an archive from your script and its resources, uploads it, and runs the test on cloud infrastructure while streaming status to your terminal:

k6 cloud run script.js

To run the test locally and stream only the results to Grafana Cloud, use --local-execution:

k6 cloud run --local-execution script.js

k6 cloud run accepts the same options as k6 run, plus cloud-specific flags such as --exit-on-running and --show-logs. For local execution and result streaming, refer to Cloud output.

k6 cloud upload

Upload a test to Grafana Cloud k6 without running it. This uploads the archive k6 produces from your script and its resources:

k6 cloud upload script.js

k6 cloud project list

List all projects in the configured stack.

Usage

k6 cloud project list [flags]

Options

Option	Description
`--json`	Output the project list as a JSON array. Without this flag, the output is a human-readable table.

Output

The default output is a table with the project ID, NAME, and whether it’s the stack’s DEFAULT project:

Projects for https://my-team.grafana.net:

ID       NAME               DEFAULT
123456   default            yes
234567   Checkout service   no

k6 cloud test list

List the load tests of a Grafana Cloud k6 project.

The project to list tests for is resolved in the following order:

The --project-id flag.
The K6_CLOUD_PROJECT_ID environment variable (cloud config projectID).
The default project of the configured stack, populated by k6 cloud login.

If none of these resolve to a project, the command returns an error.

Usage

k6 cloud test list [flags]

Options

Option	Description
`--project-id`	ID of the project to list tests for. Defaults to the configured project.
`--json`	Output the test list as a JSON array. Without this flag, the output is a human-readable table.

Output

The default output is a table with each test’s ID, NAME, and CREATED and UPDATED timestamps (in UTC):

Tests in project 123456:

ID       NAME              CREATED            UPDATED
789012   Checkout flow     2026-01-15 09:30   2026-02-01 14:22
789013   Homepage load     2026-01-20 11:05   2026-01-28 08:47

k6 cloud load-zone list

List all load zones available in the configured stack, including the public (Grafana-managed) zones and any private load zones you’ve set up. Use it to confirm a zone’s identifier and whether it’s currently usable before you reference it from a script.

Usage

k6 cloud load-zone list [flags]

Options

Option	Description
`--json`	Output the load zone list as a JSON array. Without this flag, the output is a human-readable table.

Output

The default output is a table with each zone’s ID (the identifier you reference from a script, such as amazon:us:ashburn), NAME, TYPE (public or private), and whether it’s currently AVAILABLE:

Load zones for https://my-team.grafana.net:

ID                    NAME                     TYPE      AVAILABLE
amazon:us:ashburn     Ashburn, US (Amazon)     public    yes
amazon:sa:cape town   Cape Town, SA (Amazon)   public    yes
my-cluster            My private cluster       private   no

With --json, the same data is emitted as a JSON array:

[
  {
    "id": 1,
    "k6_load_zone_id": "amazon:us:ashburn",
    "name": "Ashburn, US (Amazon)",
    "public": true,
    "available": true
  },
  {
    "id": 2,
    "k6_load_zone_id": "my-cluster",
    "name": "My private cluster",
    "public": false,
    "available": false
  }
]

To learn how to reference load zones from a test, refer to Declare load zones from the CLI.

Glossary

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

Glossary

What we talk about when we talk about k6.

In discussion about k6, some terms have a precise, technical meaning. If a certain term in these docs confuses you, consult this list for a definition.

Application performance monitoring

(Or APM). The practice of monitoring the performance, availability, and reliability of a system.

Concurrent sessions

The number of simultaneous VU requests in a test run.

Checks

Checks are true/false conditions that evaluate the content of some value in the JavaScript runtime.

Checks reference

Custom resource

An extension to the Kubernetes API.

Kubernetes reference

Data correlation

The process of taking dynamic data received from the system under test and reusing the data in a subsequent request.

Correlation and dynamic data example, Correlation in testing APIs

Data parameterization

The process of turning test values into reusable parameters, e.g. through variables and shared arrays.

Data parameterization examples

Dynamic data

Data that might change or will change during test runs or across test runs. Common examples are order IDs, session tokens, or timestamps.

Correlation and dynamic data example

Endurance testing

A synonym for soak testing.

Environment variables

User-definable values which may be utilized by the operating system and other programs.

Using environment variables

Execution segment

A partition, or fractional portion, of an overall test run.

The execution-segment options

Sobek

A JavaScript engine written in Go. k6 binaries are embedded with Sobek, enabling test scripting in JavaScript.

Sobek repository fork of goja.

Graceful stop

A period that lets VUs finish an iteration at the end of a load test. Graceful stops prevent abrupt halts in execution.

Graceful stop reference

Happy path

The default system behavior that happens when a known input produces an expected output. A common mistake in performance testing happens when scripts account only for the best case (in other words, the happy path). Most load tests try to discover system errors, so test scripts should include exception handling.

Happy path (Wikipedia)

HTTP archive

(Or HAR file). A file containing logs of browser interactions with the system under test. All included transactions are stored as JSON-formatted text. You can use these archives to generate test scripts (for example, with the har-to-k6 Converter).

HAR 1.2 Specification, HAR converter

Iteration

A single run in the execution of the default function, or scenario exec function. You can set iterations across all VUs, or per VU.

The test life cycle document breaks down each stage of a k6 script, including iterations in VU code.

JSON

An open standard, human-readable data-serialization format originally derived from JavaScript.

k6 Cloud

The proper name for the entire cloud product, comprising both k6 Cloud Execution and k6 Cloud Test Results.

k6 Cloud docs

k6 options

Values that configure a k6 test run. You can set options with command-line flags, environment variables, and in the script.

k6 Options

Kubernetes

An open-source system for automating the deployment, scaling, and management of containerized applications.

Kubernetes website

Load test

A test that assesses the performance of the system under test in terms of concurrent users or requests per second.

Load Testing

Load zone

The geographical instance from which a test runs.

Private load zones,Declare load zones from the CLI

Lifecycle function

A function called in a specific sequence in the k6 runtime. The most important lifecycle function is the default function, which runs the VU code.

Test lifecycle

Metric

A measure of how the system performs during a test run. http_req_duration is an example of a built-in k6 metric. Besides built-ins, you can also create custom metrics.

Metrics

Metric sample

A single value for a metric in a test run. For example, the value of http_req_duration from a single VU request.

Operator pattern

Extends Kubernetes, enabling cluster management of custom resources.

Kubernetes reference

Parallelism

The simultaneous execution of multiple tasks by dividing a problem into smaller independent parts.

Reliability

The probability that a system under test performs as intended.

Requests per second

The rate at which a test sends requests to the system under test.

Saturation

A condition when a system’s reaches full resource utilization and can handle no additional request.

Scenario

An object in a test script that makes in-depth configurations to how VUs and iterations are scheduled. With scenarios, your test runs can model diverse traffic patterns.

Scenarios reference

Scenario executor

An property of a scenario that configures VU behavior.

You can use executors to configure whether to designate iterations as shared between VUs or to run per VU, or to configure or whether the VU concurrency is constant or changing.

Executor reference

Smoke test

A regular load test configured for minimum load. Smoke tests verify that the script has no errors and that the system under test can handle a minimal amount of load.

Smoke Testing

Soak test

A test that tries to uncover performance and reliability issues stemming from a system being under pressure for an extended duration.

Soak Testing

Stability

A system under test’s ability to withstand failures and errors.

Stress test

A test that assess the availability and stability of the system under heavy load.

Stress Testing

System under test

The software that the load test tests. This could be an API, a website, infrastructure, or any combination of these.

Test run

An individual execution of a test script over all configured iterations.

Running k6

Test concurrency

In k6 Cloud, the number of tests running at the same time.

Test duration

The length of time that a test runs. When duration is set as an option, VU code runs for as many iterations as possible in the length of time specified.

Duration option reference

Test script

The actual code that defines how the test behaves and what requests it makes, along with all (or at least most) configuration needed to run the test.

Single Request example.

Threshold

A pass/fail criteria that evaluates whether a metric reaches a certain value. Testers often use thresholds to codify SLOs.

Threshold reference

Throughput

The rate of successful message delivery. In k6, throughput is measured in requests per second.

Virtual user

(Or VU). The simulated users that run separate and concurrent iterations of your test script.

The VU option

YAML

Rhymes with “camel,” provides a human-readable data-serialization format commonly used for configuration files.

Versioning and stability guarantees

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

Versioning and stability guarantees

As innovation sometimes requires introducing bold and extensive changes that might impact the workflow of k6’s consumers, our goal is to ensure stability, predictability, and ease of use for all users of k6, including those leveraging it in the cloud and other products built on top of the open source project.

In the following sections, we define workflows, guarantees, and constraints applied to k6 software, starting with version v1.0.0.

Note
This document serves as an explicit allow list policy. Only APIs specifically mentioned within this document are covered by our stability guarantees. Any API not explicitly included is not covered by this policy and may be subject to breaking changes.

If you believe an API should be added to this allow list but is currently missing, please open a new issue in the k6 repository to initiate discussion on its potential inclusion.

Versioning strategy

k6 strictly follows the Semantic Versioning 2.0.0 versioning scheme. This versioning scheme defines three kinds of software versions, categorizing their relationship to the key concept of breaking changes.

Breaking change

As per the Semantic Versioning 2.0.0 specification, we define a breaking change as a change to k6 that’s not backward compatible.

Breaking changes imply that the consumer of k6 is expected to make some effort to adapt to the changes being made.

Major version

A major version contains backward incompatible API changes.

Quoting the SemVer 2.0.0 specification on major versions directly:

Major version X (X.y.z | X > 0) MUST be incremented if any backward-incompatible changes are introduced to the public API. This may also include minor and patch-level changes. Patch and minor versions MUST be reset to 0 when the major version is incremented.

While it’s possible that a new major version with breaking changes may remain compatible with the previous version, this should not be expected.

Minor version

A minor version contains backward-compatible API additions/changes.

Quoting the SemVer 2.0.0 specification on minor versions directly:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward-compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch-level changes. The patch version MUST be reset to 0 when the minor version is incremented.

Patch version

A patch version contains bug fixes that do not affect the API.

Quoting the SemVer 2.0.0 specification on patch versions directly:

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.

Release strategy

A k6 release is a set of changes that updates or adds new functionalities to the product, made globally available under a unique and new identifiable version.

k6 follows and aligns with the Grafana Labs release stages. Not all changes follow every step of the release stages in a strict or sequential manner. Most of the changes directly pass from Experimental to General availability (GA).

Frequency

The release schedule for new k6 versions is:

Version	Cadence
Major	Once per year
Minor	Every six weeks
Patch	As needed, based on priorities

In alignment with the practice observed in the Grafana ecosystem, this allows us to maintain a regular rhythm, offering opportunities for better feature planning, communication, and visibility around releases, as well as regular cleanup of deprecated functionalities, helping reduce technical debt over time.

What is our stable and supported API surface?

In defining the stable API surface for k6, we aim to provide clear and stable interfaces guaranteed to be maintained and supported according to our versioning strategy. Our stable and supported API surface includes several key components, each critical for our users and their integration workflows.

Any change to one of the APIs described below will be considered breaking. Note that the following list is intended as an allowlist, and any APIs, libraries, or components not explicitly mentioned are considered excluded. For example, the k6 REST API is an example of an accessible API not covered by the supported API surface.

Options & command-line interface

Our stable and supported API surface includes the k6 options set, as exposed to users via the various configuration methods k6 supports: the options object, config file, environment variables, etc.

The k6 command-line interface (CLI), including commands, subcommands, and flags, is also part of the stable and supported API. These commands are essential for initiating and managing test executions locally and in the cloud.

JavaScript interpreter

With k6 scripts written in JavaScript and the environment in which they are executed supporting a specific set of JavaScript syntax and ECMAScript features, the k6 JavaScript interpreter is considered part of the k6 stable and supported API surface.

This ensures that users can write and execute scripts with predictable behavior and compatibility over the lifespan of their major version of k6.

Modules

The core modules exposed directly to a script by k6, for example, k6, k6/http, k6/execution, are another critical aspect of the k6 experience and of the interface between k6 and its users. As such, they’re part of the stable and supported API surface. It includes any class, properties, methods, function, or relative signature that is part of the module and is publicly exposed and documented.

The full list of the core modules is avalilable on the JavaScript API page.

Experimental modules, recognizable from their k6/experimental prefixed import path, are explicitly excluded from the stable and supported API surface.

Extensions

Our stable and supported API surface also includes the extensions API, which empowers internal and external developers to build custom modules and outputs as part of the k6 codebase or as external extensions.

It covers any package publicly available in go.k6.io/k6/v2. Consequentially, all the packages under go.k6.io/k6/v2/internal package are excluded.

This includes the go.k6.io/k6/v2/js/modules Go package that internal and external developers have available to build module extensions, as well as the go.k6.io/k6/v2/output that can be used to build custom outputs for k6.

It also includes public k6 Go packages that are exposed to developers to facilitate the development of these extensions. For example, the current go.k6.io/k6/v2/lib package where the go.k6.io/k6/v2/lib.State type is placed.

Output

We guarantee the stability and support of metrics, logs, traces, and profiling outputs that we fully control in an end-to-end flow. This includes the JSON, CSV, cloud metrics, logs and traces outputs, and OpenTelemetry formats while excluding outputs dependent on third-party platforms and protocols.

Metrics

We guarantee the stability of metric names, types, and units. Any changes to these are considered breaking and will be handled according to our versioning strategy. Doing so ensures that any product or artifact built on top of k6, such as dashboards, can maintain a reliable and consistent experience.

Deprecation, breaking changes, and migration policy

Breaking changes

In a constantly evolving product, breaking changes are sometimes unavoidable. They require that k6 users actively react to them because the state after the changes is not backward compatible with the previous state.

Because we follow the SemVer 2.0.0 versioning scheme, we work under the assumption breaking changes will always lead to a new major version. When the k6 team decides to introduce a breaking change, it will automatically define the need for a new major version.

When k6 releases a new major version, we are expected to be explicit, clearly communicate the breaking changes, and provide instructions for migrating users.

There are two types of breaking changes:

Removal
Update

When a breaking change is added, the k6 team will follow the following steps:

Remove an API or a feature

Deprecate a current API or a feature by following the dedicated policy.
If necessary, add an alternative solution. Ideally, this would be an experimental version within a minor release within the current maintained state. Alternatively, it might be available in a Preview release.
Provide documentation for the migration path.
Proceed with removing the API and releasing a new major version.

Update an API or a feature

Apply the changes, then publish them in the next major version. If the change is significant, it might be convenient to make it available in a Preview release that can support the migration path until a version is globally available.
Provide documentation for the migration path.

Deprecation

When the k6 team intends to remove an API or a feature, it will be marked as deprecated. This occurs when an API becomes obsolete, superseded by another API, or otherwise discontinued for business or technological reasons. Deprecated APIs remain available during their deprecation phase, and we guarantee they will be maintained for the entire lifecycle of the current major version.

A deprecation will be announced through several layers of communication before it will be officially applied:

Release notes.
Official documentation.
When the user directly interacts with the feature.
An alternative already available is recommended, but it shouldn’t be considered mandatory.

Migration

When a breaking change is introduced, or an API is superseded, then documentation for a migration guide will be provided to users to help them understand how to move from version to version. The migration path will be available in the official documentation, and it will be mentioned in all other communication channels.

Support and development policies

We define k6 support and development policies according to four states where a k6 version can be implemented. At any given time, we have:

The under-development version is the next upcoming version of k6. Note that this version might either start a new major version, for example, developing v3.0.0 while the latest release is v2.8.2, or it might be a new minor or patch iteration over the latest release.
The actively maintained version is the latest released major version of k6.
The supported version is the latest released version of k6 within the previous major version.
The deprecated versions are the set of previously released k6 versions.

As such, during its development and support workflow, the k6 open source project actively develops the next version of k6, maintains the latest major release, supports the previous major version, and doesn’t provide any support for releases older than the supported one.

Any past version of k6 that’s neither being developed, maintained, or supported is considered deprecated and will not receive further updates or development, including bug fixes or security updates. Users are free to use them at their own risk.

Guidelines

Features are not backported from one major version to any previous one.
Only changes on the latest release of each support category are provided: at any point in time, there are single officially under-development and actively maintained versions. We do not support multiple versions of each support path. For example, suppose a bug is found in v1.1.0, and the latest v1.Y.Z published release is v1.3.2. In that case, if and only if the latest release is affected, and the bug or security issue is deemed important enough, only then does the development team define as a priority to publish a fix that will be released in v1.3.3. Users cannot expect a v1.1.1 fix release.
Other Grafana products, services, and teams building upon k6 are expected to develop their versioning integration built on our support policies.

Bugs & Security issues

Bugs and security issues come in all shapes and sizes and vary widely in impact. Some are critical, compromising user safety or impacting software functionality, while others are minor annoyances that do not require immediate action.

The k6 open-source core team, with input from affected stakeholders, is responsible for assessing the severity of these issues.

We classify bug severity based on their impact on users or product functionality. High-severity bugs prevent a subset of users from using the software properly or at all. Depending on the severity, the team will either release an immediate patch or, for less critical bugs, delay the fix to the next scheduled release.

Security issues are classified using the CVSS (Common Vulnerability Scoring System) score when available. In its absence, we evaluate the threat in collaboration with the security team and affected teams. This assessment considers the potential threat to customers, users, system health, and data integrity. Like bug fixes, the response will be either an immediate patch release for high-severity issues or a delayed fix for lower-severity issues.

Guarantees

Under development

At any point in the k6 development lifecycle, the next version of k6 is being developed.

The next version of k6 can be a major, minor, or patch one. This developed version is then released according to our versioning strategy and scheme and becomes the latest maintained version of k6.

Actively maintained

The latest version, released under the currently active major version, is maintained.

In the event of a bug, security issue, or necessary dependency update:

If the under-development version is expected to remain within the same major version scope, the fix or update is expected to land in said version, which will become, in turn, the next maintained version once released.
If the under-development version is expected to switch to a new major version scope, the fix or update will be included in the currently maintained major version scope and released as the latest maintained version (patch).

Supported k6 version

At any point, the prior major version will be in support mode. The supported version of k6 will receive no further updates or features backport but will keep receiving major and security bug fixes. Its minor version is not expected to change anymore, and it should only see its patch version grow.

Deprecated k6 versions

A major version of k6, which is two major versions away from the past (for example, v1.0.0, when the latest version is v3.0.0), is considered deprecated and won’t receive any form of support anymore. The same applies to a minor version.

Real-world scenarios

A major (bug or security) issue is found with the latest release of k6

The latest release of k6 is actively maintained. Within this version’s major scope is a single maintained version, the latest one.

Thus, when a security issue or bug affects the actively maintained version, the k6 team puts together a fix and publishes a new patch version of the currently maintained version. Although the under-development version should integrate those changes, we still reserve the right to release a new intermediary release.

If the issue or bug also affects the supported version of k6, we apply the fix to it and publish a patch version of the currently supported version of k6.

If the issue also affects a deprecated version of k6, we take no action and invite users to upgrade to at least the latest supported version of k6.

An issue is found in the supported version of k6

When a security issue or bug is found in the currently supported version of k6, the k6 team creates a fix in the support version’s branch. It publishes a new patch version of the supported version, which becomes the new supported version of k6.

If the issue also affects the k6 version, which is currently the major version, a separate fix should be released as a patch version within the maintained version’s major scope.

If the issue also affects deprecated versions of k6, we take no action and invite users to upgrade to at least the latest supported version of k6.

An issue is found in a deprecated version of k6

If an issue (security-related or a bug) is found in a deprecated version, we do not take action and recommend that users upgrade to a supported version of k6.

Experimental

Within k6, some APIs, features, and modules are explicitly marked as experimental.

Those APIs, features, and modules are either made of changes or new capabilities, which we believe are valuable to our users and the development of k6. Still, they are not yet stable.

An experimental API, feature, or module can undergo a breaking change and be completely removed without prior notice. Our support policy does not cover experimental APIs, features, and modules. As such, we advise products, projects, and teams not to rely on them explicitly for mission-critical operations and to build upon them if possible.

They should be marked and communicated internally and, most importantly, externally. When a user interacts with an experimental feature or module, it must be explicitly communicated to them. How to do it depends on the layer where the change is introduced and can vary case by case.

For example, a JavaScript module should be recognizable as an experimental module by its import path, which includes the k6/experimental/ prefix. Advertising the experimental state via the official documentation is also highly encouraged. However, using it as a unique level shouldn’t be considered sufficient communication. The development team is responsible for deciding what the reasonable level is based on the specific case.

Experimental APIs, features, and modules may eventually become stable. When that happens, it will lead to a new minor version of k6 in most cases. The experimental module import path becomes deprecated and will be removed in a couple of minor releases with a future notice.

Versioning policy

We reserve ourselves the right to modify the versioning strategy and policies as part of a major release, under the constraints that:

We maintain a changelog of the modifications we do in the document itself.
The document remains public and accessible to users.
We communicate changes in the context of new releases.

For example, let’s assume we decide to introduce a new supported API surface, like the REST API v2. We would amend this document accordingly and publish and enforce the change to the affected workflows as part of the next major release.

Reference on Grafana Labs

Integrations & Tools

Integrations & Tools

Test authoring

AI assistants (MCP)

IDE extensions

Converters

Result store and visualization

Continuous Integration and Continuous Delivery

Chaos engineering

Test management

Archive Command

Archive Command

What is an archive?

How to create and run an archive

⚠️ Overriding options

Use cases

Sharing a test

Preparing tests for CI

k6 Cloud Execution

Uploading an archive to k6 Cloud

Distributed Execution

Contents of an archive file

What an archive file does not contain

Cloud commands

Cloud commands

Authentication

k6 cloud login

k6 cloud run

k6 cloud upload

k6 cloud project list

Usage

Options

Output

k6 cloud test list

Usage

Options

Output

k6 cloud load-zone list

Usage

Options

Output

Glossary

Glossary

Application performance monitoring

Concurrent sessions

Checks

Custom resource

Data correlation

Data parameterization

Dynamic data

Endurance testing

Environment variables

Execution segment

Sobek

Graceful stop

Happy path

HTTP archive

Iteration

JSON

k6 Cloud

k6 options

Kubernetes

Load test

Load zone

Lifecycle function

Metric

Metric sample

Operator pattern

Parallelism

Reliability

Requests per second

Saturation

Scenario

Scenario executor

Smoke test

Soak test

Stability

Stress test

System under test