Grafana k6 release notes on Grafana Labs

Version 2.3.0 release notes

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

Version 2.3.0 release notes

k6 v2.3.0 is here 🎉! This release includes:

A --scenario flag to run selected parts of a test without editing the script.
A --once flag to reuse load-test scripts for smoke and functional testing.
Experimental async group() support that keeps metrics in the right group across await.
Built-in byte encoding, Set operations, and raw JSON values.
Opt-in fetching of missing TLS certificates for servers that work in browsers but fail in k6.
Static labels for Prometheus remote write, nanosecond log timestamps, and WebSocket ready-state constants.

New features

Run selected scenarios #6360

When a script tests several services or user journeys, you may only need to run the part you are working on. The new --scenario flag lets you select named scenarios without editing the script, adding environment-variable selection code, or splitting it into separate scripts. This addresses the long-standing request to run a subset of scenarios.

For example, this script defines two workloads:

import http from 'k6/http';

export const options = {
  scenarios: {
    homepage: {
      executor: 'shared-iterations',
      exec: 'homepage',
      vus: 2,
      iterations: 10,
    },
    contacts: {
      executor: 'shared-iterations',
      exec: 'contacts',
      vus: 1,
      iterations: 5,
    },
  },
};

export function homepage() {
  http.get('https://test.k6.io/');
}

export function contacts() {
  http.get('https://test.k6.io/contacts.php');
}

Run only the homepage workload, keeping its two VUs and ten total iterations:

k6 run --scenario homepage script.js

Select multiple scenarios with comma-separated names:

k6 run --scenario homepage,contacts script.js

Each selected scenario keeps its executor, load, timing, function, environment, tags, and browser options. Without the flag, k6 runs all configured scenarios. Selection also works with k6 cloud run and k6 archive; archives retain the selected configuration.

Names must match configured scenarios. Load shortcuts such as --vus and --duration cannot be combined with selection; set the workload in each scenario instead. k6 warns and skips thresholds tagged for configured scenarios you exclude, while keeping global thresholds and other filters. See the scenario documentation for details.

Run a script once with `--once` #6338

The --once flag is now the recommended way to run a script once, for both protocol and browser tests, while preserving the scenario’s function and browser configuration. It supports scripts with at most one scenario and works with k6 run, k6 cloud run, and k6 archive. For example, this configuration runs checkout() repeatedly with ten VUs for 30 seconds:

export const options = {
  scenarios: {
    checkout: {
      executor: 'constant-vus',
      exec: 'checkout',
      vus: 10,
      duration: '30s',
    },
  },
};
// The rest of the script defines checkout().

k6 run --once script.js

With --once, k6 changes this scenario to shared-iterations with one VU and one iteration, calling checkout() once instead of repeatedly for 30 seconds. Previously, shortcuts such as --vus 1 --iterations 1 replaced the script’s scenarios with a default scenario, discarding settings such as the selected function and browser options. This broke browser scripts because the configuration needed to launch Chromium was missing; --once keeps that configuration. To combine scenario selection with --once, see Run each selected scenario once.

Keep metrics grouped across asynchronous calls #6340, #6341, #6342, #6343, #6344

You can now use an async function in group() by enabling the experimental async-metric-context feature. Requests and checks after an await keep their group, and group_duration measures until the callback’s returned promise settles. Previously, group() rejected async functions, and promise callbacks could lose the group tag.

import { check, group } from 'k6';
import http from 'k6/http';

export default async function () {
  await group('browse', async () => {
    const response = await http.asyncRequest('GET', 'https://test.k6.io/');
    check(response, { 'page loaded': (r) => r.status === 200 });
    await http.asyncRequest('GET', 'https://test.k6.io/contacts.php');
  });
}

k6 run --features async-metric-context script.js

Both requests and the check belong to browse, including the work after the first await. The feature also preserves custom tags and metadata across promises, timer callbacks, k6/websockets listeners, and gRPC stream listeners. Changes inside a group or callback stay local to that work and its asynchronous descendants instead of leaking into unrelated work.

Fetch missing TLS certificates #6137

Some HTTPS servers work in browsers but fail in k6 because they omit an intermediate certificate. The new tlsAIAFetch option lets k6 fetch that missing certificate while still verifying the server’s identity:

export const options = {
  tlsAIAFetch: true,
};

This is opt-in and works with HTTP and gRPC connections. Thanks, @vtorosyan!

Static labels for Prometheus remote write #6071

When several k6 instances send metrics to the same Prometheus server, labels let you tell their results apart. Use K6_PROMETHEUS_RW_LABELS to identify the job, environment, or server on every time series sent by that output:

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

Thanks, @rohan-patnaik!

Nanosecond log timestamps #6310

Logs with second-precision timestamps can lose their order when a log service sorts messages emitted within the same second. Enable nanosecond timestamps with --log-ns-timestamps to make those messages easier to order and correlate:

k6 --log-ns-timestamps --log-format=json run script.js

This also works with plain-text logs when --no-color is set.

WebSocket ready-state constants #6306

The WebSocket constructor and its instances now expose the same connection-state constants as browsers: CONNECTING, OPEN, CLOSING, and CLOSED. For an existing socket, you can check its state before sending a message:

if (socket.readyState === WebSocket.OPEN) {
  socket.send('hello');
}

Encode bytes and compare sets with JavaScript built-ins #6382

You can now convert Uint8Array data to and from hex or base64 with built-in methods, and compare sets with operations such as difference(), intersection(), and union(). Use them to prepare binary test data or check which fields are missing from a response.

const bytes = Uint8Array.fromHex('6b36');
console.log(bytes.toBase64()); // azY=

const expected = new Set(['id', 'name', 'email']);
const received = new Set(['id', 'name']);
console.log([...expected.difference(received)]); // ["email"]

The Sobek update also adds Error.isError(), JSON.rawJSON(), and JSON.isRawJSON(). For example, JSON.rawJSON() lets you include an exact numeric value in a JSON payload without rounding it to a JavaScript Number first:

JSON.stringify({ id: JSON.rawJSON('9007199254740993') });
// '{"id":9007199254740993}'

Thanks to @arukiidou and @xtrafrancyz for the upstream implementations!

Read the execution result before k6 exits #6388

When k6 stays alive with --linger, tools monitoring the process cannot use its exit status to tell whether the test finished successfully or aborted. The REST API’s /v1/status response now includes execution_result, with the test’s exit code once it is known. Before then, the field is null. Thanks, @yorugac!

For example, query a lingering process after a script calls exec.test.abort():

curl -s http://localhost:6565/v1/status | jq '.data.attributes.execution_result'

{
  "exit_code": 108
}

UX improvements and enhancements

#6408 Explains how to enable experimental async support when group() rejects an async callback.
#6402 Fixes a missing space in the --no-usage-report help text. Thanks, @yats0x7!
#6339 Adds login and token-configuration guidance when Grafana Cloud commands return an authentication error. Thanks, @Swapnil-Biswas!

Bug fixes

#6414 Stops screenshot capture from waiting until the page closes when a browser command does not respond, so scripts can catch the timeout and continue cleanup.
#6412 Lets waits for hidden or detached browser elements finish when the element is already absent, instead of timing out or throwing an error.
#6368 Makes crypto.getRandomValues() throw a catchable TypeError instead of crashing k6 when called without an argument or with a typed array whose length was overridden to a negative value. Thanks, @hyuraku!
#6327 Fixes a data race when closing a browser context while other browser operations access it. Thanks, @JohnPei1!
#6351 Prevents clearing an expired timer from running a later timeout or interval too early, and fixes VUs hanging when a k6/websockets connection is closed before its handshake finishes.
#6349 Fixes inflated http_req_sending and http_req_duration values when making HTTPS requests through an HTTPS proxy. Thanks, @kausthubhk!
#5922 Stops the test with an error when a ramping-VU scenario cannot start a VU, instead of silently stopping the scenario and reporting success. Thanks, @HwangRock!
#6163 Preserves Web Vitals from intermediate pages when a browser test navigates several times in the same tab, so results include those pages as well as the last one.
#6355 Prevents a response-body leak when reading a digest authentication challenge fails. Thanks, @cuishuang!
#5949 Supports sending metrics to InfluxDB behind a reverse proxy with a URL path prefix, such as https://host/influxdb/database. Thanks, @o6ivp!
#6235 Uses forward slashes in remote screenshot paths on Windows. Thanks, @adarshsm!
#6238 Sends null and undefined form fields as empty values instead of the string <nil>, and warns when a nested object cannot be encoded as a form field. Thanks, @djedi-knight!
#6279 Fixes browser tests stalling when VUs share a remote Chrome instance, so pages can run concurrently.
#6298 Preserves browser trace spans that were lost when a test ended. Thanks, @mem!
#6385 Fixes an integer overflow that prevented compilation on 32-bit ARM and x86 systems. Thanks, @GourangaDasSamrat!

Maintenance and internal improvements

#6413 Updates the browser role-selector test fixture for Chromium’s image-map rendering.
#6369, #6370 Adds the binary’s build origin and a locally stored random installation ID to usage reports, helping distinguish build sources and measure active installations. Both respect --no-usage-report.
#6209 Simplifies the internal handling of Cloud commands. Thanks, @moko-poi!
#6236 Adds a smoke test before publishing browser Docker images to catch missing or broken Chromium installations.
#6245 Enables CI on the v1 maintenance branch.
#6246, #6277 Automates approvals and merging for eligible dependency updates.
#6256, #6271 Improves contributor acknowledgments and the release checklist.
#6270 Restores Debian package publishing after bzip2 was removed from the packaging base image.
#6301, #6373 Corrects the TC39 test-package path and built-in module locations in contributor documentation. Thanks, @umekikazuya and @ashrafiucse!
#6312, #6380, #6394, #6398 Uses shared CI workflows, lint configuration, and Go test versions, and fixes findings from the newer linter.
#6409 Updates Test262 expectations for Unicode tests that pass with the newer Go version.
#6325 Moves browser option parsing into the JavaScript mapping layer without changing script behavior. Thanks, @Shobhit-Nagpal!
#6265, #6266, #6267, #6303, #6304, #6331, #6332, #6357, #6358, #6363, #6367, #6383, #6376, #6478 Updates the Docker build image to Go 1.27.1, raises the module’s minimum Go version to 1.26.0, and updates gRPC to v1.84.0 (the example server uses v1.83.2), OpenTelemetry to v1.46.0, Brotli to v1.2.3, klauspost/compress to v1.20.0, esbuild to v0.28.2, Testify to v1.12.1, Protobuf to v1.36.12, golang.org/x/crypto to v0.56.0, and related Go dependencies.

External contributors

Thanks to @adarshsm, @arukiidou, @ashrafiucse, @cuishuang, @djedi-knight, @GourangaDasSamrat, @HwangRock, @hyuraku, @JohnPei1, @kausthubhk, @mem, @moko-poi, @o6ivp, @rohan-patnaik, @Shobhit-Nagpal, @Swapnil-Biswas, @umekikazuya, @vtorosyan, @xtrafrancyz, @yats0x7, and @yorugac for their contributions.

Version 2.2.0 release notes

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

Version 2.2.0 release notes

k6 v2.2.0 is here 🎉! This release includes:

k6 cloud run --local-execution now streams k6’s logs to Grafana Cloud, so the test run’s log view works for local execution too.
chromium.connectOverCDP(), which connects browser tests to an already-running Chromium instance.
TextEncoder and TextDecoder available as globals, and WritableStream support in k6/experimental/streams.
A k6 cloud load-zone list command.
Two new experimental feature flags: merge-run-tags and freeze-env.

Breaking changes

There are no breaking changes in this release.

New features

`k6 cloud run --local-execution` streams logs to Grafana Cloud #6171

When a cloud test runs locally with k6 cloud run --local-execution, k6’s logs now stream to the Grafana Cloud test run, so the run’s log view is populated the same way it is for cloud execution. Use the new --no-cloud-logs flag to opt out of streaming logs when working with --local-execution:

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

Connect to a running browser with `chromium.connectOverCDP()` #6165

The browser module can now attach to an existing Chromium-based browser over the Chrome DevTools Protocol, mirroring Playwright’s browserType.connectOverCDP(). Pass the browser’s WebSocket endpoint and k6 manages the returned browser’s connection — it’s auto-closed at the end of the iteration, though you can call close() earlier to release the connection on demand.

import { chromium } from 'k6/browser';

export default async function () {
  const browser = await chromium.connectOverCDP('ws://localhost:9222/devtools/browser/<id>');
  const page = await browser.newPage();

  try {
    await page.goto('https://quickpizza.grafana.com/');
  } finally {
    await page.close();
    await browser.close();
  }
}

Unlike the K6_BROWSER_WS_URL environment variable, the endpoint is a runtime value — you can, for example, request a fresh session URL from a browser provider’s API in setup() and connect to it from the iterations.

`TextEncoder` and `TextDecoder` globals #6182

TextEncoder and TextDecoder are now available as standard globals in both the init and VU contexts, no import required — matching how they are exposed in browsers and other JavaScript runtimes.

const encoded = new TextEncoder().encode('Hello, world!');
const decoded = new TextDecoder().decode(encoded);

`WritableStream` in `k6/experimental/streams` #6132

The experimental streams module now implements WritableStream and WritableStreamDefaultWriter following the WHATWG Streams specification, complementing the existing ReadableStream.

import { WritableStream } from 'k6/experimental/streams';

export default async function () {
  const stream = new WritableStream({
    write(chunk) {
      console.log(`wrote ${chunk}`);
    },
  });

  const writer = stream.getWriter();
  await writer.write('hello');
  await writer.close();
}

`k6 cloud load-zone list` command #6142

A new k6 cloud load-zone list subcommand lists the load zones — public and private — available in the configured Grafana Cloud k6 stack, mirroring the existing k6 cloud project list command. Output defaults to a human-readable table; pass --json to emit a JSON array instead.

$ k6 cloud load-zone list
Load zones for https://example.grafana.net:

ID                     NAME                     TYPE      AVAILABLE
amazon:us:ashburn      Ashburn, US (Amazon)     public    yes
amazon:sa:cape town    Cape Town, SA (Amazon)   public    yes

Configurable `handleSummary()` timeout #5854

The time budget for the handleSummary() callback — previously hardcoded to 120 seconds — is now configurable through the handleSummaryTimeout option or the K6_HANDLE_SUMMARY_TIMEOUT environment variable, so long-running tests with heavy summaries no longer fail with handleSummary() execution timed out. Thanks, @LBaronceli!

export const options = {
  handleSummaryTimeout: '5m',
};

New experimental feature flags: `merge-run-tags` and `freeze-env`

Two new experimental feature flags join the feature-flag system introduced in v2.1.0:

#5714 merge-run-tags merges run tags per key across config layers, so options.tags in a script is no longer silently discarded when --tag or K6_TAGS is also used. Thanks, @yordis!
#6032 freeze-env freezes the __ENV object, so modifications from script code throw a TypeError (in strict mode) instead of silently persisting across iterations and scenarios. Thanks, @lohitkolluri!

k6 run --features merge-run-tags,freeze-env script.js

For a full list of changes, including UX improvements and bug fixes, refer to the full release notes.

Version 1.7.1 release notes

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

Version 1.7.1 release notes

k6 v1.7.1 is here 🎉! This release includes:

Dependency updates for google.golang.org/grpc.

Maintenance and internal improvements

#5746 Updates google.golang.org/grpc which contains a fix for CVE-2026-33186.

Version 1.7.0 release notes

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

Version 1.7.0 release notes

k6 v1.7.0 is here 🎉! This release includes:

Automatic resolution for subcommand extensions — no more manual xk6 builds required to use them!
K6_SECRET_SOURCE env var as an alternative to --secret-source, accepting the same syntax.

Breaking changes

There are no breaking changes in this release.

New features

Automatic resolution for subcommand extensions #5664

You can now rely on automatic extension resolution also when using a subcommand extension that isn’t included in the current binary.

Previously, using extension subcommands required manually building a custom k6 binary with xk6. Now, k6 detects the missing extension, provisions the binary on demand, and executes the command transparently — the same experience already available for JavaScript extensions.

For instance, if you run:

k6 x httpbin

and the xk6-subcommand-httpbin subcommand extension isn’t in the current binary, k6 will automatically provision a binary with it on demand and execute the command transparently.

Roadmap

k6 v2.0.0 is the next planned release. It will include a set of breaking changes that have been discussed and planned. You can find the list of planned breaking changes in #5062.

Version 1.6.0 release notes

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

Version 1.6.0 release notes

k6 v1.6.0 is here 🎉! This release includes:

Cloud commands now support configurable default Grafana Cloud stack.
New k6 deps command for analyzing script dependencies.
Browser APIs enhancements with frameLocator(), goBack(), goForward() methods.
Crypto module adds PBKDF2 support for password-based key derivation.
jslib gets a new TOTP library for time-based one-time password generation and validation.
New mcp-k6 MCP server for AI-assisted k6 script writing.

Breaking changes

There are no breaking changes in this release.

New features

Configurable default stack for Cloud commands #5420

Cloud commands now support configuring the default Grafana Cloud stack you want to use. The stack slug (or stack id) is used by the Cloud to determine which default project to use when not explicitly provided.

Previously, users had to specify the project id for every test run. With this change, you can configure a default stack during login, and k6 will use it to automatically resolve the appropriate default project. This is particularly useful for organizations with multiple Grafana Cloud stacks or when working across different teams and environments.

Users can also set up a specific stack for every test run, either using the new option stackID or the environment variable K6_CLOUD_STACK_ID.

Please note that, in k6 v2, this stack information will become mandatory to run a test.

# Login interactively and select default stack
k6 cloud login

# Login and set default stack with token
k6 cloud login --token $MY_TOKEN --stack my-stack-slug

# Run test using the configured default stack
k6 cloud run script.js

# Run test using a specific stack
K6_CLOUD_STACK_ID=12345 k6 cloud run script.js

# Stack id can also be set in the options
export const options = {
  cloud: {
    stackID: 123,
    projectID: 789,  // If the project does not belong to the stack, this will throw an error
  },
};

This simplifies the cloud testing workflow and prepares k6 for upcoming changes to the Grafana Cloud k6 authentication process, where the stack will eventually become mandatory.

`k6 deps` command and manifest support #5410, #5427

A new k6 deps command is now available to analyze and list all dependencies of a given script or archive. This is particularly useful for understanding which extensions are required to run a script, especially when using auto extension resolution.

The command identifies all imports in your script and lists dependencies that might be needed for building a new binary with auto extension resolution. Like auto extension resolution itself, this only accounts for imports, not dynamic require() calls.

# Analyze script dependencies
k6 deps script.js

# Output in JSON format for programmatic consumption
k6 deps --json script.js

# Analyze archived test dependencies
k6 deps archive.tar

This makes it easier to understand extension requirements, share scripts with clear dependency information, and integrate k6 into automated build pipelines.

In addition, k6 now supports a manifest that specifies default version constraints for dependencies when no version is defined in the script using pragmas. If a dependency is imported without an explicit version, it defaults to “*”, and the manifest can be used to replace that with a concrete version constraint.

The manifest is set through an environment variable as JSON with keys being a dependency and values being constraints:

K6_DEPENDENCIES_MANIFEST='{"k6/x/faker": ">=v0.4.4"}' k6 run scripts.js

In this example, if the script only imports k6/x/faker and does not use a use k6 with k6/x/faker ... directive, it will set the version constraint to >=v0.4.4. It will not make any changes if k6/x/faker is not a dependency of the script at all.

Browser module: `frameLocator()` method #5487

The browser module now supports frameLocator() on Page, Frame, Locator, and FrameLocator objects. This method creates a locator for working with iframe elements without the need to explicitly switch contexts, making it much easier to interact with embedded content.

Frame locators are particularly valuable when testing applications with nested iframes, as they allow you to chain locators naturally while maintaining readability:

Click to expand example code

import { browser } from 'k6/browser';

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
};

export default async function () {
  const page = await browser.newPage();

  try {
    await page.goto('https://example.com');

    // Locate an iframe and interact with elements inside it
    const frame = page.frameLocator('#payment-iframe');
    await frame.locator('#card-number').fill('4242424242424242');
    await frame.locator('#submit-button').click();

    // Chain frame locators for nested iframes
    const nestedFrame = page
      .frameLocator('#outer-frame')
      .frameLocator('#inner-frame');
    await nestedFrame.locator('#nested-content').click();
  } finally {
    await page.close();
  }
}

This complements existing frame handling methods and provides a more intuitive API for working with iframe-heavy applications.

Browser module: `goBack()` and `goForward()` navigation methods #5494

The browser module now supports page.goBack() and page.goForward() methods for browser history navigation. These methods allow you to navigate the page’s history, similar to clicking the browser’s back/forward buttons.

Click to expand example code

import { browser } from 'k6/browser';

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
};

export default async function () {
  const page = await browser.newPage();

  try {
    await page.goto('https://example.com');
    await page.goto('https://example.com/page2');
    
    // Navigate back to the previous page
    await page.goBack();
    
    // Navigate forward again
    await page.goForward();
    
    // Both methods support optional timeout and waitUntil parameters
    await page.goBack({ waitUntil: 'networkidle' });
  } finally {
    await page.close();
  }
}

Browser module: Request event handlers #5481, #5486

The browser module now supports page.on('requestfailed') and page.on('requestfinished') event handlers, enabling better monitoring and debugging of network activity during browser tests.

The requestfailed event fires when a request fails (network errors, aborts, etc.), while requestfinished fires when a request completes successfully.

Click to expand example code

import { browser } from 'k6/browser';

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
};

export default async function () {
  const page = await browser.newPage();

  // Monitor failed requests
  page.on('requestfailed', (request) => {
    console.log(`Request failed: ${request.url()}`);
  });

  // Monitor successful requests
  page.on('requestfinished', (request) => {
    console.log(`Request finished: ${request.url()}`);
  });

  await page.goto('https://example.com');
  await page.close();
}

These event handlers provide deeper insights into network behavior during browser testing and help identify issues that might not be immediately visible.

Crypto module: PBKDF2 support #5380

The crypto module now supports PBKDF2 for deriving cryptographic keys from passwords. PBKDF2 is widely used for password hashing and key derivation in security-sensitive applications, and this addition enables testing of systems that use PBKDF2 for authentication or encryption.

For usage examples, check out the one provided in the repository or refer to the documentation.

WebSockets module is now stable #5586

The websockets module has been promoted to stable status and is now available via the k6/websockets path. The experimental k6/experimental/websockets module will be removed in a future release. Users should migrate to the stable k6/websockets module.

To migrate, simply update your import statement:

// Old (experimental)
import ws from 'k6/experimental/websockets';

// New (stable)
import ws from 'k6/websockets';

No other changes are required because the API is the same.

Console logging: ArrayBuffer and TypedArray support #5496

console.log() now properly displays ArrayBuffer and TypedArray objects, making it easier to debug binary data handling in your test scripts. Previously, these types would not display useful information, making debugging difficult when working with binary protocols, file uploads, or WebSocket binary messages.

Click to expand example code

// Log ArrayBuffer - shows detailed byte contents
const buffer = new ArrayBuffer(8);
const view = new Int32Array(buffer);
view[0] = 4;
view[1] = 2;
console.log(buffer);
// Output: ArrayBuffer { [Uint8Contents]: <04 00 00 00 02 00 00 00>, byteLength: 8 }

// Log TypedArrays - shows type, length, and values
const int32 = new Int32Array([4, 2]);
console.log(int32);
// Output: Int32Array(2) [ 4, 2 ]

// Nested objects with TypedArrays
console.log({ v: int32 });
// Output: { v: Int32Array(2) [ 4, 2 ] }

// Complex nested structures
console.log({ 
  name: "test", 
  buffer: buffer, 
  view: int32 
});
// Output: { name: "test", buffer: ArrayBuffer {...}, view: Int32Array(2) [...] }

Configurable TLS version for Experimental Prometheus output #5537

The experimental Prometheus remote write output now supports configuring the minimum TLS version used for connections. This allows you to meet specific security requirements or compatibility constraints when sending metrics to Prometheus endpoints.

If not set, the default minimum TLS version is 1.3.

K6_PROMETHEUS_RW_TLS_MIN_VERSION=1.3 k6 run script.js -o experimental-prometheus-rw

A new TOTP library k6-totp

A new TOTP (Time-based One-Time Password) library is now available in jslib.k6.io, enabling k6 scripts to generate and validate time-based one-time passwords. This is particularly useful for testing applications that use TOTP-based two-factor authentication (2FA), such as authenticator apps like Google Authenticator or Authy. See the documentation at k6-totp.

Click to expand example code

import http from 'k6/http';
import { TOTP } from 'https://jslib.k6.io/totp/1.0.0/index.js';

export default async function () {
  // Initialize TOTP with your secret key (base32 encoded)
  // The second parameter is the number of digits (typically 6 or 8)
  const totp = new TOTP('GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ', 6);

  // Generate the current TOTP code
  const code = await totp.gen();
  console.log(`Generated TOTP code: ${code}`);

  // Use the TOTP code in authentication
  const response = http.post('https://api.example.com/login', JSON.stringify({
    username: 'user@example.com',
    password: 'password123',
    totpCode: code
  }), {
    headers: { 'Content-Type': 'application/json' }
  });

  // Optionally verify a TOTP code
  const isValid = await totp.verify(code);
  console.log(`Code is valid: ${isValid}`);
}

The library follows the standard TOTP RFC 6238 specification, ensuring compatibility with standard authenticator applications.

Introducing mcp-k6: AI-assisted k6 script writing mcp-k6

mcp-k6 is an experimental Model Context Protocol (MCP) server for k6. Once connected to your AI assistant or MCP-compatible editor (such as Cursor, VS Code, or Claude Desktop), it helps you write better k6 scripts faster and run them with confidence.

With mcp-k6, your AI assistant can:

Write accurate scripts: Create up-to-date scripts by referring to embedded k6 documentation and TypeScript definitions to reduce API hallucinations.
Validate scripts: Catch syntax errors, missing imports, and export default function declarations before execution.
Run tests locally: Execute scripts and review results without leaving your editor.
Generate scripts: Create tests from requirements using guided prompts that follow k6 best practices.
Convert browser tests: Transform Playwright tests into k6 browser scripts while preserving test logic.

To get started, install mcp-k6 via Docker, Homebrew, or from source, then configure it with your editor. See the documentation for installation instructions and setup guides.

Roadmap

We’ve started looking into k6 v2! The major release will focus on introducing breaking changes that have accumulated throughout the v1.x series, such as removing deprecated APIs and changing default behaviors. New features will continue to be incrementally released in v1.x minor versions as usual until the v2.0.0 release.

Version 1.5.0 release notes

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

Version 1.5.0 release notes

k6 v1.5.0 is here 🎉! This release includes:

Changes in the browser module:
- page.waitForEvent() for event-based synchronization with page events.
- locator.pressSequentially() for character-by-character typing simulation.
Improved debugging with deep object logging in console.log().
Extended WebSocket support with close code and reason information.
Enhanced extension ecosystem with custom subcommands and DNS resolver access.
URL-based secret management for external secret services.
New machine-readable summary format for test results.

Breaking changes

As per our stability guarantees, breaking changes across minor releases are allowed only for experimental features.

Breaking changes for experimental modules

#5237 Deprecates the experimental/redis module. The module will be removed in a future release. Users should migrate to alternative solutions, such as the official k6 Redis extension.

New features

`page.waitForEvent()` #5478

The browser module now supports page.waitForEvent(), which blocks the caller until a specified event is captured. If a predicate is provided, it waits for an event that satisfies the predicate. This method is particularly valuable for testing scenarios where you need to synchronize your test flow with specific browser or page events before proceeding with the next action.

Event-driven synchronization is vital for test reliability, especially when dealing with asynchronous operations where timing is unpredictable. This is more robust than using fixed delays and helps avoid flaky tests.

import { browser } from 'k6/browser';

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
};

export default async function () {
  const page = await browser.newPage();

  // Wait for a console message containing specific text
  const msgPromise = page.waitForEvent('console', msg => msg.text().includes('hello'));
  await page.evaluate(() => console.log('hello world'));
  const msg = await msgPromise;
  console.log(msg.text());
  // Output: hello world

  // Wait for a response from a specific URL with timeout
  const resPromise = page.waitForEvent('response', {
    predicate: res => res.url().includes('/api/data'),
    timeout: 5000,
  });
  await page.click('button#fetch-data');
  const res = await resPromise;

  await page.close();
}

`locator.pressSequentially()` #5457

The browser module now supports locator.pressSequentially(), which types text character by character, firing keyboard events (keydown, keypress, keyup) for each character. This method is essential for testing features that depend on gradual typing to trigger specific behaviors, such as autocomplete suggestions, real-time input validation per character, or dynamic character counters. Thank you, @rajan2345, for the contribution 🎉

The method supports a configurable delay between keystrokes, enabling you to simulate realistic typing speeds and test time-dependent input handlers:

import { browser } from 'k6/browser';

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
};

export default async function () {
  const page = await browser.newPage();

  try {
    await page.goto('https://test.k6.io/browser.php');

    // Type text character by character
    const searchInput = page.locator('#text1');
    await searchInput.pressSequentially('Hello World');

    // Type with delay to simulate realistic typing speed
    await searchInput.clear();
    await searchInput.pressSequentially('test query', { delay: 100 });
  } finally {
    await page.close();
  }
}

This complements existing text input methods: locator.fill() for simple form filling, locator.type() for gradual typing without keyboard events, and now pressSequentially for character-by-character typing with full keyboard event firing. Thank you, @rajan2345, for the contribution 🎉

`console.log()` Deep Object Logging #5460

console.log() now properly traverses and displays complex JavaScript structures, including functions, classes, and circular references. Previously, Sobek’s JSON marshaling would lose nested functions, classes, and other non-serializable types, making debugging painful.

Objects with mixed function and class properties are now properly displayed:

console.log({
  one: class {},
  two: function() {}
});
// Before: {}
// After:  {"one":"[object Function]","two":"[object Function]"}

Nested arrays and objects with functions are now fully traversed:

console.log([
  { handler: class {} },
  { data: [1, 2, class {}] }
]);
// Before: [{},{"data":[1,2,null]}]
// After:  [{"handler":"[object Function]"},{"data":[1,2,"[object Function]"]}]

Complex objects with multiple property types are properly preserved:

console.log({
  a: [1, 2, 3],
  b: class {},
  c: () => {},
  d: function() {},
  e: [1, () => {}, function() {}, class {}, 2]
});
// Before: {"a":[1,2,3],"e":[1,null,null,null,2]}
// After:  {
//   "a":[1,2,3],
//   "b":"[object Function]",
//   "c":"[object Function]",
//   "d":"[object Function]",
//   "e":[1,"[object Function]","[object Function]","[object Function]",2]
// }

Circular references are now properly detected and marked:

const obj = {
  fn: function() {},
  foo: {}
};
obj.foo = obj;

console.log(obj);
// Before: [object Object]
// After:  {"fn":"[object Function]","foo":"[Circular]"}

This improvement makes debugging k6 test scripts significantly easier when working with API responses, event handlers, and complex state objects.

`experimental/websockets` - Close Code and Reason Support #5376

The experimental WebSockets module now supports sending close codes and reasons when closing connections, and properly captures close event information. This is essential for testing WebSocket implementations that rely on specific close codes to determine whether a connection was closed normally or due to an error.

import ws from 'k6/experimental/websockets';

export default function () {
  const socket = ws.connect('ws://example.com', (socket) => {
    socket.on('close', (data) => {
      console.log(`Connection closed with code: ${data.code}, reason: ${data.reason}`);
      // Output: Connection closed with code: 1000, reason: Normal closure
    });
  });

  // Close with code and reason
  socket.close(1000, 'Normal closure');
}

Thanks, @etodanik, for the contribution 🎉

Subcommand Extension Support #5399

Extensions can now register custom subcommands under the k6 x namespace, enabling custom command-line tools that integrate seamlessly with k6. This provides a consistent and discoverable way for extensions to offer specialized CLI utilities while maintaining k6’s familiar command structure.

Extensions can now define custom commands like:

k6 x my-tool --help
k6 x debug --inspect

This integration pattern allows extension authors to provide powerful tooling that feels native to the k6 ecosystem.

DNS Resolver Access #5421

Extensions can now access k6’s DNS resolver for custom DNS handling and networking extensions. The resolver respects k6’s configuration including hosts overrides, custom DNS servers, and DNS caching settings. This enables extensions to use it directly instead of having to reproduce the functionality. Which also makes them work the same way as native modules.

Machine-Readable Summary Format #5338

A new machine-readable summary format for the end-of-test summary is now available, providing structured, programmatic shapes via --summary-export and handleSummary(). This format is designed for easier integration with external systems and analytics pipelines.

The new format is currently opt-in via the --new-machine-readable-summary flag or K6_NEW_MACHINE_READABLE_SUMMARY environment variable, and will become the default in k6 v2:

k6 run script.js --new-machine-readable-summary --summary-export=summary.json

This makes it easier to integrate k6 results into CI/CD pipelines, dashboards, and custom analysis tools.

URL-Based Secret Management #5413

The secret management system now supports URL-based secret sources, allowing k6 to fetch secrets from HTTP endpoints. This lets users implement a simple HTTP API to provide secrets to a test. There is a mock implementation, but no particular production-ready implementation is provided at this time. In the future, there is potential for proxies to other systems, including HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault.

Roadmap

Deprecation of First Input Delay (FID) Web Vital

Following the official web vitals guidance, First Input Delay (FID) is no longer a Core Web Vital as of September 9, 2024, having been replaced by Interaction to Next Paint (INP). The k6 browser module already emits INP metrics, and we’re planning to deprecate FID support to align with industry standards.

FID only measures the delay before the browser runs your event handler, so it ignores the time your code takes and the delay to paint the UI—often underestimating how slow an interaction feels. INP captures the full interaction latency (input delay + processing + next paint) across a page’s interactions, so it better reflects real user-perceived responsiveness and is replacing FID.

Action required

If you’re currently using FID in your test scripts for thresholds or relying on it in external integrations, you should migrate to using INP as soon as possible.

// Instead of relying on FID
export const options = {
  thresholds: {
    // 'browser_web_vital_fid': ['p(95)<100'], // Deprecated
    'browser_web_vital_inp': ['p(95)<200'], // Use INP instead
  },
};

This change ensures k6 browser testing stays aligned with modern web performance best practices and Core Web Vitals standards.

For a full list of changes, including UX improvements and bug fixes, refer to the full release notes.

Version 1.4.0 release notes

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

Version 1.4.0 release notes

k6 v1.4.0 is here 🎉! This release includes:

OpenTelemetry output graduated from experimental to stable status.
Changes in the Browser module:
- page.waitForRequest for waiting on specific HTTP requests.
- QueryAll methods now return elements in DOM order.
- locator.evaluate and locator.evaluateHandle for executing JavaScript code in the page context with access to the matching element.
- page.unroute(url) and page.unrouteAll for removing routes registered with page.route.

Breaking changes

As per our stability guarantees, breaking changes across minor releases are allowed only for experimental features.

Breaking changes for experimental modules

#5164 OpenTelemetry output now exports rate metrics as a single counter with zero/nonzero labels instead of separate metrics.
#5333 OpenTelemetry output configuration: K6_OTEL_EXPORTER_TYPE is deprecated in favor of K6_OTEL_EXPORTER_PROTOCOL to align with OpenTelemetry standards.

Breaking changes for undefined behaviours

#5320, #5239, #5342 Automatic extension resolution now only inspects ES module import statements and no longer supports CommonJS require() calls. CommonJS require() calls are dynamic, and it is not possible to know for certain if they will be called, or if they will be called with static strings - the only way they were even previously loaded. This functionality was a quirk of the previous implementation and had numerous problems. Additionally, use k6 directives are now only recognized when they appear at the beginning of files (after optional shebang and whitespace/comments). This was the original intention, but due to implementation bugs, it did not accurately reflect what was happening.

New features

OpenTelemetry output graduation #5334

The OpenTelemetry output has graduated from experimental status and is now available as a stable output using the name opentelemetry. This change makes OpenTelemetry the recommended vendor-agnostic solution for exporting k6 telemetry data.

You can now use the stable output name in your k6 commands:

# Previous experimental usage (still supported for backward compatibility)
k6 run --out experimental-opentelemetry script.js

# New stable usage
k6 run --out opentelemetry script.js

The experimental-opentelemetry name will continue to work for backward compatibility for now but it’s deprecated and we might remove it in future versions. We recommend migrating to use the new opentelemetry name.

`page.waitForRequest` #5330

The browser module now supports page.waitForRequest(), which allows you to wait for HTTP requests that match specific URL patterns during browser automation. This method is particularly valuable for testing scenarios where you need to ensure specific network requests are initiated before proceeding with test actions.

The method supports multiple URL pattern matching strategies:

// Wait for exact URL match
const requestPromise = page.waitForRequest('https://api.example.com/data');
await page.click('button[data-testid="load-data"]');
const request = await requestPromise;

// Wait for regex pattern match
await page.waitForRequest(/\/api\/.*\.json$/);

// Use with Promise.all for coordinated actions
await Promise.all([
  page.waitForRequest('https://api.example.com/user-data'),
  page.click('button[data-testid="load-user-data"]')
]);

This complements the existing page.waitForResponse() method by focusing on HTTP requests rather than responses, providing more granular control over network-dependent test scenarios.

`page.unroute(url)` and `page.unrouteAll()` #5223

The browser module now supports page.unroute(url) and page.unrouteAll(), allowing you to remove routes previously registered with page.route.

Example usage:

await page.route(/.*\/api\/pizza/, function (route) {
  console.log('Modifying request to /api/pizza');
  route.continue({
    postData: JSON.stringify({
      customName: 'My Pizza',
    }),
  });
});
...

await page.unroute(/.*\/api\/pizza/); // The URL needs to be exactly the same as the one used in the call to the `route` function

await page.route(/.*\/api\/pizza/, function (route) {
  console.log('Modifying request to /api/pizza');
  route.continue({
    postData: JSON.stringify({
      customName: 'My Pizza',
    }),
  });
});
...

await page.unrouteAll();

`locator.evaluate` and `locator.evaluateHandle` #5306

The browser module now supports locator.evaluate and locator.evaluateHandle, allowing you to execute JavaScript code in the page context with access to the matching element. The only difference between evaluate and evaluateHandle is that evaluateHandle returns a JSHandle.

Example usage:

await check(page, {
  'calling evaluate': async p => {
    const n = await p.locator('#pizza-name').evaluate(pizzaName => pizzaName.textContent);
    return n == 'Our recommendation:';
  }
});

await check(page, {
  'calling evaluate with arguments': async p => {
    const n = await p.locator('#pizza-name').evaluate((pizzaName, extra) => pizzaName.textContent + extra, ' Super pizza!');
    return n == 'Our recommendation: Super pizza!';
  }
});

const jsHandle = await page.locator('#pizza-name').evaluateHandle((pizzaName) => pizzaName);

const obj = await jsHandle.evaluateHandle((handle) => {
  return { innerText: handle.innerText };
});
console.log(await obj.jsonValue()); // {"innerText":"Our recommendation:"}

New officially supported k6 DNS extension

The xk6-dns extension is now officially supported in k6 OSS and k6 Cloud. You can import k6/x/dns directly in your scripts thanks to automatic extension resolution, with no custom build required.

Use it to perform DNS resolution testing as part of your tests: resolve names via custom or system DNS, measure resolution latency and errors, validate records before HTTP steps, compare resolvers, and even load test DNS servers in end‑to‑end scenarios.

For example:

import dns from 'k6/x/dns';

export default function () {
  const answer = dns.resolve('grafana.com', { recordType: 'A' });
  console.log(answer.records.map(({ address }) => address).join(', '));
}

The extension currently supports A and AAAA record lookups. If you would like to see additional record types supported, please consider contributing to the extension.

Automatic extension resolution improvements #5320, #5239, #5342, #5332, #5240

Automatic extension resolution has been completely reimplemented to use k6’s internal module loader instead of the external k6deps/esbuild pipeline. This change brings significant improvements in reliability and maintainability.

As part of the rewrite, a few issues and unintended features were found, namely:

Trying to follow require calls, which, due to their dynamic nature, don’t work particularly stably. That is, depending on where and how the require call was used, k6 might decide whether it is needed or not. And it definitely doesn’t work when using actual string variables. Support for CommonJS is primarily for backward compatibility, so after an internal discussion, we opted not to support it at all. We could bring this back until v2, if there is enough interest. However, in the long term, it is intended that this not be part of k6.
“use k6 with …” directives were parsed from the whole file instead of just the beginning, which leads to numerous problems, and was not the intended case. As such, they are now only parsed at the beginning of files (not just the main one) with potential empty lines and comments preceding them.

Example:

// main.js
"use k6 with k6/x/faker"
import { faker } from 'k6/x/faker';
import { helper } from './utils.js';

export default function() {
  console.log(faker.name());
  helper();
}

Or, an example using the directive with CommonJS

// utils.js
"use k6 with k6/x/redis"
const redis = require('k6/x/redis');

exports.helper = function() {
  // Use redis extension
}

In this example, k6 will detect both k6/x/faker and k6/x/redis extensions from the use k6 directives in both files and provision a binary that includes both extensions if needed.

Other fixes this brings are:

Fixes for path related issues (irregardless of usage of the feature) on windows, especially between drives. It is possible there were problems on other OSes that were just not reported. #5176
Syntax errors were not reported as such, as the underlying esbuild parsing will fail, but won’t be handled well. #5127, #5104
Propagating exit codes from a sub-process running the new k6. This lets you use the result of the exit code.

For a full list of changes, including UX improvements and bug fixes, refer to the full release notes.

Version 1.3.0 release notes

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

Version 1.3.0 release notes

k6 v1.3.0 is here 🎉! This release includes:

Browser module gets:
- locator.locator, locator.contentFrame, and FrameLocator.locator for powerful locator chaining and iframe handling.
- locator|frame|FrameLocator.getBy* for targeting elements without relying on brittle CSS selectors.
- locator.filter for filtering locators for more precise element targeting.
- locator.boundingBox for retrieving element geometry.
- page.waitForResponse for waiting on specific HTTP responses.

Deprecations

A new summary mode `disabled` has been introduced to replace the “no summary” option #5118

The --no-summary flag and its corresponding environment variable K6_NO_SUMMARY have been deprecated in favor of the new disabled summary mode. This change unifies the configuration experience for controlling the end-of-test summary.

You can now disable the end-of-test summary with either --summary-mode=disabled or K6_SUMMARY_MODE=disabled.

The `legacy` summary mode has been deprecated #5138

The legacy summary mode was introduced in k6 v1.0, when the end-of-test summary was revamped with the addition of two new modes: compact and full.

Its purpose was to ease the transition for users who relied heavily on the old summary format. However, we’ve now reached the point where it’s time to deprecate it.

The plan is to fully remove it in k6 v2.0, so please migrate to either compact or full to ensure readiness for the next major release.

New features

`locator.locator` #5073

The locator.locator method allows you to define locators relative to a parent locator, enabling powerful locator chaining and nesting. This feature lets you create more precise element targeting by combining multiple selectors in a hierarchical manner.

await page
  .locator('[data-testid="inventory"]')
  .locator('[data-item="apples"]')
  .locator('button.add')
  .click();

This nesting capability provides a more intuitive way to navigate complex DOM structures and serves as the foundation for other locator APIs in this release that require such hierarchical targeting.

`locator.contentFrame` #5075

The browser module now supports locator.contentFrame(), which returns a new type frameLocator. This method is essential for switching context from the parent page to iframe contents.

frameLocator types target iframe elements on the page and provide a gateway to interact with their contents. Unlike regular locators that work within the current frame context, frameLocators specifically target iframe elements and prepare them for content interaction.

This approach is essential for iframe interaction because:

Iframes create separate DOM contexts that require special handling.
Browsers enforce security boundaries between frames.
Iframe content may load asynchronously and needs proper waiting.
Using elementHandle for iframe interactions is error-prone and can lead to stale references, while frameLocator provide reliable, auto-retrying approaches.

Example usage:

// Get iframe element and switch to its content frame
const iframeLocator = page.locator('iframe[name="payment-form"]');
const frame = await iframeLocator.contentFrame();

`frameLocator.locator` #5075

We’ve also added frameLocator.locator which allows you to create locators for elements inside an iframe. Once you’ve targeted an iframe with page.contentFrame(), you can use .locator() to find and interact with elements within that iframe’s content with the frameLocator type.

Example usage:

// Target an iframe and interact with elements inside it
const iframe = page.locator('iframe[name="checkout-frame"]').contentFrame();
await iframe.locator('input[name="card-number"]').fill('4111111111111111');
await iframe.locator('button[type="submit"]').click();

This functionality enables testing of complex web applications that use iframes for embedded content, payment processing, authentication widgets, and third-party integrations.

`locator.boundingBox` #5076

The browser module now supports locator.boundingBox(), which returns the bounding box of an element as a rectangle with position and size information. This method provides essential geometric data about elements on the page, making it valuable for visual testing, and layout verification.

Using locator.boundingBox() is recommended over elementHandle.boundingBox() because locators have built-in auto-waiting and retry logic, making them more resilient to dynamic content and DOM changes. While element handles can become stale if the page updates, locators represent a live query that gets re-evaluated, ensuring more reliable test execution.

The method returns a rectangle object with x, y, width, and height properties, or null if the element is not visible:

// Get bounding box of an element
const submitButton = page.locator('button[type="submit"]');
const rect = await submitButton.boundingBox();

Locator filtering #5114, #5150

The browser module now supports filtering options for locators, allowing you to create more precise and reliable element selections. This enhancement improves the robustness of your tests by enabling you to target elements that contain or exclude specific text, reducing reliance on brittle CSS selectors.

locator.filter() creates a new locator that matches only elements containing or excluding specified text.

// Filter list items that contain specific text
const product2Item = page
  .locator('li')
  .filter({ hasText: 'Product 2' });

// Filter items that do NOT contain specific text using regex
const otherProducts = page
  .locator('li')
  .filter({ hasNotText: /Product 2/ });

It’s also possible to filter locators during their creation with options.

page.locator(selector, options) creates page locators with optional text filtering:

// Create locators with text filtering during creation
const submitButton = page.locator('button', { hasText: 'Submit Order' });
await submitButton.click();

frame.locator(selector, options) creates frame locators with optional text filtering:

// Filter elements within frame context
const frame = page.mainFrame();
const input = frame.locator('input', { hasNotText: 'Disabled' });

locator.locator(selector, options) chains locators with optional text filtering:

// Chain locators with filtering options
await page
  .locator('[data-testid="inventory"]')
  .locator('[data-item="apples"]', { hasText: 'Green' })
  .click();

frameLocator.locator(selector, options) create locators within iframe content with optional text filtering:

// Filter elements within iframe content
const iframe = page.locator('iframe').contentFrame();
await iframe.locator('button', { hasText: 'Submit Payment' }).click();

`frame.getBy`, `locator.getBy`, `frameLocator.getBy*` #5105, #5106, #5135

The browser module now supports all getBy* methods on frame, locator, and frameLocator types, expanding on the page.getBy* APIs introduced in v1.2.1. This enhancement provides consistent element targeting across all browser automation contexts, improving Playwright compatibility and offering more flexible testing workflows. The available methods on all types are:

getByRole() - Find elements by ARIA role
getByText() - Find elements by text content
getByLabel() - Find elements by associated label text
getByPlaceholder() - Find elements by placeholder text
getByAltText() - Find elements by alt text
getByTitle() - Find elements by title attribute
getByTestId() - Find elements by data-testid attribute

Examples across different types

// Frame context
const frame = page.mainFrame();
await frame.getByRole('button', { name: 'Submit' }).click();
await frame.getByLabel('Email').fill('user@example.com');

// Locator context (for scoped searches)
const form = page.locator('form.checkout');
await form.getByRole('textbox', { name: 'Card number' }).fill('4111111111111111');
await form.getByTestId('submit-button').click();

// FrameLocator context (for iframe content)
const paymentFrame = page.locator('iframe').contentFrame();
await paymentFrame.getByLabel('Cardholder name').fill('John Doe');
await paymentFrame.getByRole('button', { name: 'Pay now' }).click();

// Chaining for precise targeting
await page
  .locator('.product-list')
  .getByText('Premium Plan')
  .getByRole('button', { name: 'Select' })
  .click();

This expansion makes k6 browser automation more versatile and aligns with modern testing practices where element targeting by semantic attributes (roles, labels, text) is preferred over fragile CSS and XPath selectors.

`page.waitForResponse` #5002

The browser module now supports page.waitForResponse(), which allows you to wait for HTTP responses that match specific URL patterns during browser automation. This method is particularly valuable for testing scenarios where you need to ensure specific network requests complete before proceeding with test actions.

The method supports multiple URL pattern matching strategies:

// Wait for exact URL match
await page.waitForResponse('https://api.example.com/data');

// Wait for regex pattern match
await page.waitForResponse(/\/api\/.*\.json$/);

// Use with Promise.all for coordinated actions
await Promise.all([
  page.waitForResponse('https://api.example.com/user-data'),
  page.click('button[data-testid="load-user-data"]')
]);

This complements the existing waitForURL method by focusing on HTTP responses rather than navigation events, providing more granular control over network-dependent test scenarios.

Thank you, @HasithDeAlwis, for contributing this feature.

Roadmap

Deprecation of First Input Delay (FID) Web Vital

Planned timeline

v1.4.x+: Deprecation warnings will appear in the terminal when FID metrics are used #5179.
Grafana Cloud k6: Similar deprecation warnings will be shown in the cloud platform.
v2.0: Complete removal of FID metric support.

Action required

If you’re currently using FID in your test scripts for thresholds or relying on it in external integrations, you should migrate to using INP as soon as possible.

// Instead of relying on FID
export const options = {
  thresholds: {
    // 'browser_web_vital_fid': ['p(95)<100'], // Deprecated
    'browser_web_vital_inp': ['p(95)<200'], // Use INP instead
  },
};

This change ensures k6 browser testing stays aligned with modern web performance best practices and Core Web Vitals standards.

OpenTelemetry stabilization

We aim to stabilize OpenTelemetry’s experimental metric output, promoting vendor neutrality for metric outputs. OpenTelemetry is becoming the standard protocol for metric format in observability. Our goal is to enable k6 users to utilize their preferred metric backend storage without any technological imposition.

For a full list of changes, including UX improvements and bug fixes, refer to the full release notes.

Version 1.2.0 release notes

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

Version 1.2.0 release notes

k6 v1.2.0 is here 🎉! This release includes:

Automatic extension resolution (previously Binary Provisioning) enabled for everyone
gRPC gets better handling of NaN and Infinity float values and easier health check
Browser module gets page.route, all the page.getBy* APIs, locator.all(), and page.waitForURL

Breaking changes

As per our stability guarantees, breaking changes across minor releases are allowed only for experimental features.

Breaking changes for experimental modules

The experimental Open Telemetry and Prometheus outputs now default to TLSv1.3. This should’ve been the default to begin with. It is not expected that anyone should be affected, apart from making it more secure for the metrics output to send messages.

New features

Automatic extension resolution

k6 extensions allow you to add custom functionality to your tests, such as connecting to databases, message queues, or specialized networking protocols. Previously, using extensions required manual building of a custom k6 binary with the extensions compiled in. This new version introduces the Automatic Extension Resolution functionality, previously named Binary Provisioning, which is enabled by default and automatically detects when your script imports extensions and handles the complexity of provisioning the right k6 binary for you.

import faker from "k6/x/faker";

export default function () {
  console.log(faker.person.firstName());
}

The previous experimental versions only supported official extensions. #4922 added the support to use any extension listed in the community list by setting the K6_ENABLE_COMMUNITY_EXTENSIONS environment variable.

K6_ENABLE_COMMUNITY_EXTENSIONS=true k6 run script.js

Note, Community extensions are only supported for local test executions (using k6 run or k6 cloud run --local-execution). When running tests on Grafana Cloud k6, only official extensions are allowed.

Check out the new extensions documentation for additional details.

Handling of NaN and Infinity float values in gRPC #4631

Previously, float values of NaN or Infinity were marshalled as null. This has now changed to use their string representation, aligning with other gRPC APIs.

There are no changes required in the scripts.

This is also the first contribution by @ariasmn. Thank you @ariasmn for taking the time to make the PR and answer all our questions.

Health check for gRPC APIs #4853

The k6 gRPC module now has a client.healthCheck() method that simplifies checking the status of a gRPC service. This method eliminates the need for manual invoke calls, making it particularly useful for readiness checks and service discovery.

Before, you had to write boilerplate code to perform a health check:

import grpc from 'k6/grpc';

const client = new grpc.Client();
// ...
const response = client.invoke('grpc.health.v1.Health/Check', { service: 'my-service' });

Now, you can simplify this with the healthCheck() method:

import grpc from 'k6/grpc';

const client = new grpc.Client();
client.connect('grpc.test.k6.io:443');

// Check the health of a specific service
const response = client.healthCheck('my-service');

// Check the health of the overall gRPC server
const overallResponse = client.healthCheck();

client.close();

Check out the client.healthCheck documentation for additional details. Thank you, @tbourrely, for contributing this feature.

Assertions Library (Preview) #4067

k6 now provides an assertions library to help you verify your application behaves as expected during testing.

The library introduces the expect function with a set of expressive matchers. Pass a value to expect() and chain it with a matcher that defines the expected outcome. The library caters to both protocol testing HTTP/API and browser testing scenarios.

The API is inspired by Playwright’s assertion syntax, offering a fluent interface for more readable and reliable tests.

import { expect } from 'https://jslib.k6.io/k6-testing/0.5.0/index.js';
import { browser } from 'k6/browser';
import http from 'k6/http';

export function protocolTest() {
  // Get the home page of k6's Quick Pizza app
  const response = http.get('https://quickpizza.grafana.com/');

  // Simple assertions
  expect(response.status).toBe(200);
  expect(response.error).toEqual('');
  expect(response.body).toBeDefined();
}

export async function browserTest() {
  const page = await browser.newPage();

  try {
    await page.goto('https://quickpizza.grafana.com/');

    // Assert the "Pizza Please" button is visible
    await expect(page.locator('button[name=pizza-please]')).toBeVisible();
  } finally {
    await page.close();
  }
}

export const options = {
  scenarios: {
    // Protocol tests
    protocol: {
      executor: 'shared-iterations',
      vus: 1,
      iterations: 1,
      exec: 'protocolTest',
    },

    // Browser tests
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
      exec: 'browserTest',
    },
  },
};

Preview feature

This feature is ready to use, but still in preview:

No breaking changes are neither planned, nor expected.
Some functionality may be missing or rough around the edges.
We expect to keep adding matchers and improving coverage.

We welcome your feedback, and invite you to share your suggestions and contributions on GitHub.

Add `page.getByRole` API #4843

The browser module now supports page.getByRole(), which allows you to locate elements based on their ARIA roles. This provides a more semantic and accessible way to find elements, making your tests more robust and aligned with how users actually interact with web applications.

ARIA roles represent the purpose or function of an element (like button, link, textbox, etc.), making them excellent selectors for testing since they’re less likely to change when the UI is refactored compared to CSS classes or IDs.

Example usage:

// Find elements by role
await page.getByRole('button').click();

// Find elements by role and accessible name
await page.getByRole('button', { name: 'Submit' }).click();

// `name` works with regex too
await page.getByRole('textbox', { name: /^Username$/ }).fill('admin');

// Work with specific states
await page.getByRole('checkbox', { name: 'Accept terms', checked: true }).click();

// Find headings by level
await page.getByRole('heading', { level: 2, name: 'Section Title' }).textContent();

### Add `page.getByAltText` [#4881](https://github.com/grafana/k6/pull/4881)

The browser module now includes `page.getByAltText()`, which provides a convenient way to select elements that have an `alt` text attribute. This is particularly useful for locating images or other elements that rely on alternative text for accessibility.

Previously, you would have to use CSS or XPath selectors to find these elements:
```javascript
// Using CSS selector
const locator = page.locator('img[alt="World Map"]');

// Using XPath selector
const locator = page.locator('//img[@alt="World Map"]');

Now, you can simplify this by using getByAltText():

const locator = page.getByAltText('World Map');

// Find an image with alt text that starts with 'World'
const locator = page.getByAltText(/^World/);

Add `page.getByLabel` #4890

The browser module now includes page.getByLabel(), which provides a convenient way to locate form elements and other interactive components by their associated label text. This method works with both explicit <label> elements and elements that have an aria-label attribute, making it particularly useful for finding form inputs, buttons, and other interactive elements.

Previously, you would need to use XPath selectors to find elements by their label text, since CSS selectors cannot easily handle the relationship between labels and form elements:

// Using XPath to find input by label text  
const locator = page.locator('//label[text()="Password"]');

// Or using aria-label with CSS
const locator = page.locator('[aria-label="Username"]');

Now, you can simplify this with getByLabel():

// Works with both <label> elements and aria-label attributes
const passwordInput = page.getByLabel('Password');

// Works with regex too
const usernameInput = page.getByLabel(/^Username$/);

Add `page.getByPlaceholder` #4904

The browser module now includes page.getByPlaceholder(), which provides a convenient way to locate form elements by their placeholder text. This is particularly useful for finding input fields, textareas, and other form controls that use placeholder text to guide user input.

Previously, you would need to use CSS or XPath selectors to find elements by their placeholder attribute:

// Using CSS selector
const locator = page.locator('input[placeholder="Enter your name"]');

// Using XPath selector  
const locator = page.locator('//input[@placeholder="Enter your name"]');

Now, you can simplify this with getByPlaceholder():

const nameInput = page.getByPlaceholder('Enter your name');

// Works with regex too
const emailInput = page.getByPlaceholder(/^Email/);

Add `page.getByTitle` #4910

The browser module now includes page.getByTitle(), which provides a convenient way to locate elements by their title attribute. This is particularly useful for finding tooltips, buttons, or any other elements that use the title attribute to provide extra information.

Previously, you would need to use CSS or XPath selectors to find these elements:

// Using CSS selector
const locator = page.locator('div[title="Information box"]');

// Using XPath selector
const locator = page.locator('//div[@title="Information box"]');

Now, you can simplify this with getByTitle():

const infoBox = page.getByTitle('Information box');

// Works with regex too
const saveButton = page.getByTitle(/^Save/);

Add `page.getByTestId` #4911

The browser module now includes page.getByTestId(), which provides a convenient way to locate elements by their data-testid attribute. This is particularly useful for creating resilient tests that are not affected by changes to the UI, since data-testid attributes are specifically added for testing purposes and are not expected to change.

Previously, you would need to use CSS or XPath selectors to find these elements:

// Using CSS selector
const locator = page.locator('button[data-testid="submit-button"]');

// Using XPath selector
const locator = page.locator('//button[@data-testid="submit-button"]');

Now, you can simplify this with getByTestId():

const submitButton = page.getByTestId('submit-button');

// Works with regex too
const usernameInput = page.getByTestId(/^username/);

Add `page.getByText` #4912

The browser module now includes page.getByText(), which allows you to locate elements by their text content. This provides a convenient way to find elements like buttons, links, and other interactive components that are identified by their visible text.

Previously, you would need to use XPath selectors to find elements by their text content, since CSS selectors cannot directly query the text of an element:

// Using XPath selector
const locator = page.locator('//div[text()="Hello World"]');

Now, you can simplify this with getByText():

const helloWorldElement = page.getByText('Hello World');

// Works with regex too
const submitButton = page.getByText(/^Submit/);

Add `page.route` #4953 #4961, #4971, #4985

The browser module now supports page.route(), which allows you to intercept and handle network requests before they are sent. This is particularly useful for testing scenarios where you need to mock API responses, block certain resources, or modify request behavior.

The route handler receives a route object that provides methods to abort(), continue(), or fulfill() the request.

You can use page.route() to:

Block requests: Prevent certain resources from loading (e.g., images, ads, analytics) with abort().

// Block all image requests
await page.route(/(\.png$)|(\.jpg$)|(\.jpeg$)/, async (route) => {
    await route.abort();
});

Mock responses: Return custom responses without hitting real endpoints with fulfill().

// Mock API responses
await page.route('**/api/users', async (route) => {
    await route.fulfill({
        status: 200,
        contentType: 'application/json',
        body: JSON.stringify([{ id: 1, name: 'Mock User' }])
    });
});

Modify requests: Change headers, URL, or request body before they’re sent with continue().

// Continue with modified headers
await page.route('**/api/**', async (route) => {
    await route.continue({
        headers: {
        ...route.request().headers(),
        'Authorization': 'Bearer mock-token'
        }
    });
});

Add `locator.all()` #4899

The browser module now supports the locator.all() method, which returns an array of locators for all elements matching the selector. This is particularly useful when you need to interact with multiple similar elements on a page, such as items in a list or multiple buttons with the same styling.

Example usage:

// Get all list items and iterate through them
const items = await page.locator('li').all();
for (const item of items) {
  console.log(await item.textContent());
}

Add `waitForURL` in `frame` and `page` #4917, #4920

The browser module now includes the waitForURL method for both page and frame objects.

As a prerequiste to this enhancement, waitForNavigation now accepts a url option. This also allows you to wait for a specific URL during navigation. It is advised that you work with waitForURL instead.

The waitForURL method first checks if the current page URL already matches the expected pattern. If it does, it waits for the load state to complete. Otherwise, it waits for a navigation to the specified URL. This approach prevents race conditions where a page might complete navigation before the wait condition is set up, which is particularly useful when dealing with pages that perform multiple redirects. It supports both string patterns and regular expressions:

// Wait for navigation to a specific URL
await Promise.all([
  page.waitForURL('https://quickpizza.grafana.com/my_messages.php'),
  page.locator('a[href="/my_messages.php"]').click(),
]);

// Using regex pattern
await Promise.all([
  page.waitForURL(/.*\/contacts\.php.*/),
  page.locator('a[href^="/contacts.php"]').click()
]);

While waitForURL provides a convenient way to wait for specific URLs, we still recommend using element-based waiting strategies or the locator API with its built-in auto-waiting capabilities for more reliable tests.

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Version 1.1.0 release notes

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

Version 1.1.0 release notes

k6 v1.1.0 is here 🎉! This release includes:

New count, nth, first, and last methods for the browser module’s Locator API #4797, #4825
The k6/experimental/webcrypto module has been removed as its functionality is available globally.
Group results in the full end-of-test summary are now sorted as in code and properly indented.

Breaking changes

As per our stability guarantees, breaking changes across minor releases are allowed only for experimental features.

Breaking changes for experimental modules

Remove experimental `k6/experimental/webcrypto` module #4851

The WebCrypto API has been available globally since v1.0.0-rc1 (or v0.58.0), and now the experimental import (k6/experimental/webcrypto) is no longer available.

The required change for users is to remove the import; the rest of the code should work.

New features

New `count` method for the browser module’s Locator API #4797

The new locator.Count method returns the number of elements matching the locator. Unlike other Locator API methods, locator.Count returns the result immediately and doesn’t wait for the elements to be visible.

import { expect } from "https://jslib.k6.io/k6-testing/0.4.0/index.js";
import { browser } from 'k6/browser'

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
}

export default async function () {
  const page = await browser.newPage()
  await page.goto('https://quickpizza.grafana.com/login')

  expect(await page.locator('input').count()).toEqual(3);

  await page.close();
}

New `nth`, `first` and `last` methods for the browser module’s Locator API #4825

The new Locator API methods, nth, first, and last, can select a single element from multiple elements matched by a locator. For example, selecting a single item from a catalogue of items on an e-commerce website. Because items in this catalogue generally change often and selecting an exact element may fail in future test runs, the new methods help to prevent flaky tests, leading to more reliable tests.

import { expect } from "https://jslib.k6.io/k6-testing/0.4.0/index.js";
import { browser } from 'k6/browser'

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
}

export default async function () {
  const page = await browser.newPage()
  await page.goto('https://quickpizza.grafana.com')

  await expect(await page.locator('p').first()).toContainText('QuickPizza');
  await expect(await page.locator('p').nth(4)).toContainText('QuickPizza Labs.');
  await expect(await page.locator('p').last()).toContainText('Contribute to QuickPizza');

  await page.close();
}

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Version 1.0.0 release notes

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

Version 1.0.0 release notes

Grafana k6 v1.0 is here! 🎉

After 9 years of iteration and countless community contributions, we’re thrilled to announce Grafana k6 v1.0.

While many features and capabilities in this release were introduced gradually in previous versions, k6 v1.0 marks a turning point: a commitment to stability, formal support guarantees, and transparency in how we evolve and develop the project from here. This milestone is more than a version number; it’s about trust, reliability, and empowering you to test confidently.

Thank you, k6 community! 🌍

This release wouldn’t be possible without you:

⭐️ 27000+ GitHub stars.
🧠 9000+ git commits.
🤝 200+ contributors.
🔁 Countless test runs of any scale, in every timezone.

It’s been amazing to watch k6 grow from a simple load testing command-line tool into a comprehensive reliability tool, used by teams worldwide and supported by a passionate and dedicated community.

To everyone who filed bugs, built extensions and libraries, or championed k6:️ Thank you! You’ve shaped what k6 is today. 🙇‍♂️

What’s New in k6 1.0?

1. Stability You Can Build On

✅ Semantic Versioning: k6 now follows Semantic Versioning 2.0. Breaking changes will only happen in major releases, with prior deprecation warnings.
🔒 2-Year Support Guarantees: Every major version will be supported with critical fixes for at least two years; upgrade on your schedule.
📦 Public API Surface: We’ve established a clearly delineated and supported API surface for the k6 codebase. Extensions, integrations, and projects building on top of the k6 code now have a stable foundation to rely on.

🔎 Read more in our versioning and stability guarantees guide.

2. First-Class TypeScript Support

Write type-safe and maintainable tests—no transpilation needed. Simply save your file with a .ts extension and run it directly using k6 run script.ts.

import http from 'k6/http';  

// PizzaRequest defines the request body format the quickpizza API expects
export interface PizzaRequest {
    maxCaloriesPerSlice: number;
    mustBeVegetarian: boolean;
}

export default function () {  
    const payload: PizzaRequest = {
        maxCaloriesPerSlice: 500, // Type-checked!  
        mustBeVegetarian: true,
    }

  http.post(
    'https://quickpizza.grafana.com/api/pizza',
    JSON.stringify(payload),
    { 
        headers: { 
          "Content-Type": "application/json",
          "Authorization": "Token " + "abcdef0123456789"
        } as Record<string, string>
    });  
}

3. Extensions Made Simple

With k6 v1.0, extensions now work out of the box in k6 cloud run and k6 cloud run --local-execution. Support for k6 run is coming soon.

✅ No more xk6 toolchain. ✅ No manual builds. ✅ Import an extension’s module and go.

import faker from 'k6/x/faker';

export default function () {
  console.log(faker.person.firstName());
}

To try the experimental feature, first enable its feature flag, then run it on Grafana Cloud with the following command:

K6_BINARY_PROVISIONING=true k6 cloud run script.js,

or if you want to run it locally and stream the results to Grafana Cloud then use:

K6_BINARY_PROVISIONING=true k6 cloud run --local-execution script.js

4. Revamped test summary

The new end-of-test summary makes it easier to understand results and spot issues:

📊 Hierarchical output: Metrics are grouped by scenario, group, and category.
✅ Improved thresholds & checks: Clearer layout for faster debugging.
🔍 Multiple summary modes:
- compact (default): big picture results, focusing on essentials.
- full: full picture results, providing granularity.

k6 run --summary-mode=full script.ts

5. Quality of Life Upgrades

Stable modules: k6/browser, k6/net/grpc, and k6/crypto are now production-ready.
Improved Grafana Cloud integration: Stream local test results to Grafana Cloud with k6 cloud run --local-execution.

Version 0.57.0 release notes

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

Version 0.57.0 release notes

k6 v0.57.0 is here 🎉! This release includes:

Introducing helpers for functional testing.
The k6 new command now supports templates and ProjectIDs.
The k6/experimental/csv module gets a new asObjects option.
We no longer support the k6/experimental/browser module, in favor of k6/browser.
Moving most of non-public APIs to the internal package.

Breaking changes

#4161 Drops k6/experimental/browser. If you’re still using it, follow the instructions to move to the graduated and stable k6/browser module.
#4133 Moves all not publicly used APIs in internal package. This was based on the publicly available extensions for k6 and may break private ones. More APIs will likely be removed or updated in follow-up releases after this more mechanical change.
#4292 TypeScript is automatically supported and recognized if the script files use the .ts extension. It also deprecates experimental_enhanced compatibility mode as it is no longer necessary.

New features

New functional testing focused official jslib k6-testing

The k6 team has been developing a new official jslib dedicated to functional testing. While it is still under active development and will potentially see breaking changes, the set of APIs and behaviors it offers are meant to make their way into k6 eventually, and it is now available for early feedback.

k6-testing is a k6 JavaScript library that offers a seamless way to write functional tests in k6, using a Playwright-compatible assertions API. It exposes an expect function, with which assertions can be performed using specific matchers that reflect the expected results. Unlike current k6’s check when expects assertions fail, the test will immediately fail with a clear error message, including the expected and actual values in a similar fashion to what users would observe when using Playwright assertions.

There are many generic matchers (and more to come), such as toEqual, toBe, or toBeTruthy, to only name a few, that can be used to assert conditions during a k6 test.

import { expect } from 'https://jslib.k6.io/k6-testing/0.6.1/index.js';

export default function () {
  const response = http.get('https://test.k6.io');
  expect(response.status).toEqual(200);
  expect(response.body).toBeTruthy();
  expect(response.json()).toEqual(JSON.stringify({ message: 'Hello, world!' }));
}

k6-jslib-testing also includes browser-specific async matchers that wait until the expected condition is met such as toBeVisible, toBeDisabled, or toBeChecked, to name a few.

import { expect } from 'https://jslib.k6.io/k6-testing/0.6.1/index.js';
import { browser } from 'k6/browser';

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
};

export default async function () {
  const page = await browser.newPage();

  try {
    // Navigate to the page
    await page.goto('https://test.k6.io/my_messages.php');

    // Type into the login input field: 'testlogin'
    const loc = await page.locator('input[name="login"]');
    await loc.type('testlogin');

    // Assert that the login input field is visible
    await expect(page.locator('input[name="login"]')).toBeVisible();

    // Expecting this to fail as we have typed 'testlogin' into the input instead of 'foo'
    await expect(page.locator('input[name="login"]')).toHaveValue('foo');
  } finally {
    await page.close();
  }
}

It is currently available as part of the jslib.k6.io repository and is available to use in your k6 tests by adding the following import:

import { expect } from 'https://jslib.k6.io/k6-testing/0.6.1/index.js';

Try it out and give us feedback or contribute to the project on the k6-jslib-testing repository!

`--template` and `--project-id` flags for `k6 new` command #4153

The k6 new command has been revamped to provide an improved experience when scaffolding new k6 tests. It now supports a --template flag with options such as minimal, protocol, and browser, letting you generate a script tailored to your specific use case.

The command also now accepts a --project-id flag, which allows you to easily parameterize the test’s Grafana Cloud configuration.

# Create a new k6 script using the 'protocol' template
$ k6 new --template protocol

# Create a Grafana k6 cloud-ready script with a specific project ID
$ k6 new --project-id 12345

Refer to Create a test script using the CLI for more details.

New `asObjects` option in `k6/experimental/csv` module #4295

The CSV module’s parsing operations now support the asObjects option, which enables parsing CSV data into JavaScript objects instead of arrays of strings (the default behavior).

When asObjects is set to true, the module parses CSV data into objects where:

Column names from the header row become object keys.
Column values become the corresponding object values.
An error is thrown if no header row exists or if options modify the parsing start point.

With the option set to true,

import http from 'k6/http';
import csv from 'k6/experimental/csv';

const csvData = csv.parse('data.csv', { asObjects: true });

the following CSV file:

name,age,city
John,30,New York
Jane,25,Los Angeles

will be parsed into the following JavaScript objects:

[
  { name: 'John', age: '30', city: 'New York' },
  { name: 'Jane', age: '25', city: 'Los Angeles' },
];

Refer to the CSV module’s documentation for more information.

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Version 0.56.0 release notes

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

Version 0.56.0 release notes

k6 v0.56.0 is here 🎉! This release includes:

We’ve merged xk6-browser into k6.
Many small improvements, bug fixes and internal refactors.

Breaking changes

browser#1541 Removes accessibility-events from a test, which is no longer a valid permission that can be granted by the latest version of Chromium/Chrome.
#4093 Unexports lib/consts.FullVersion from the k6’s Golang API.

New features

Merge browser code in k6 codebase #4056

While the browser module has been stabilized, the codebase was not moved inside of k6.

As part of the stabilization this is now also merged in the k6 codebase. In the following months we would move issues from the xk6-browser repo and then archive it.

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Version 0.55.0 release notes

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

Version 0.55.0 release notes

k6 v0.55.0 is here 🎉! This release includes:

⚠️ The deprecated StatsD output has been removed.
⚠️ The experimental k6/experimental/tracing module has been removed.
🆕 URL grouping support in the browser module.
🆕 Top-level await support.
🔐 Complete RSA support for k6/experimental/webcrypto.

Breaking changes

`k6/experimental/tracing` module removed `#3855`

The experimental k6/experimental/tracing module has been removed, in favor of a replacement jslib polyfill, please consult our guide on how to migrate, #3855.

StatsD output removed `#3849`

The StatsD output was deprecated in k6 v0.47.0 and is now removed. You could still output results to StatsD using the community xk6 extension LeonAdato/xk6-output-statsd. Thanks, @LeonAdato for taking over the extension!

`open` will have a breaking change in the future.

Currently, open opens relative files based on an unusual root, similar to how require behaved before it was updated for ESM compatibility. To make k6 more consistent, open and other functions like it will start handling relative paths in the same way as imports and require. For a more in-depth explanation, please refer to the related issue.

With this version, k6 will start emitting warnings when it detects that in the future, this will break. We recommend using import.meta.resolve() as a way to make your scripts future proof.

`http.file#data` now truly has the same type as the provided data `#4009`

Previously http.file#data was always a slice of byte ([]byte) - which was very likely a bug and a leftover from years past.

The original aim (also documented) was to have the same type as the data provided when creating the http.file object, and it is now effectively the case.

New features

Top-level await support `4007`

After the initial native support for ECMAScript modules, k6 can now load those modules asynchronously which also allows await to be used in the top-level of a module. That is you can write await someFunc() directly in the top most level of a module instead of having to make an async function that you call that can than use await.

Until now, you had to wrap your code in an async function to use await in the top-level of a module. For example, the following code:

import { open } from 'k6/experimental/fs';
import csv from 'k6/experimental/csv';

let file;
let parser;
(async function () {
  file = await open('data.csv');
  parser = new csv.Parser(file);
})();

Can now be written as:

import { open } from 'k6/experimental/fs';
import csv from 'k6/experimental/csv';

const file = await open('data.csv');
const parser = new csv.Parser(file);

This should make using the increasing number of async APIs in k6 easier in the init context.

This is not allowed in case of using the CommonJS modules, only ECMAScript modules, as CommonJS modules are synchronous by definition.

Complete¹ RSA support for `k6/experimental/webcrypto` `#4025`

This update includes support for the RSA family of algorithms, including RSA-OAEP, RSA-PSS and RSASSA-PKCS1-v1_5. You can use these algorithms with the crypto.subtle API in the same way as the other algorithms, precisely for generateKey, importKey, exportKey, encrypt, decrypt, sign, and verify operations.

By implementing RSA support, we make our WebCrypto API implementation more complete and useful for a broader range of use cases.

Example usage

import { crypto } from 'k6/experimental/webcrypto';

export default async function () {
  const keyPair = await crypto.subtle.generateKey(
    {
      name: 'RSA-PSS',
      modulusLength: 2048,
      publicExponent: new Uint8Array([1, 0, 1]),
      hash: { name: 'SHA-1' },
    },
    true,
    ['sign', 'verify']
  );

  console.log(JSON.stringify(keyPair));
}

`page.on('metric)` to group urls browser#371, browser#1487

Modern websites are complex and make a high number of requests to function as intended by their developers. These requests no longer serve only content for display to the end user but also retrieve insights, analytics, advertisements, and for cache-busting purposes. Such requests are usually generated dynamically and may contain frequently changing IDs, posing challenges when correlating and analyzing your k6 test results.

When load testing a website using the k6 browser module, these dynamic requests can result in a high number of similar-looking requests, making it difficult to correlate them and extract valuable insights. This can also lead to test errors, such as a “too-many-metrics” error, due to high cardinality from metrics tagged with similar but dynamically changing URLs.

This issue also affects synthetic tests. While you may not encounter the “too-many-metrics” error, you may end up with a large amount of uncorrelated metric data that cannot be tracked effectively over time.

To address this in the browser module, we have implemented page.on('metric'), which allows you to define URL patterns using regex for matching. When a match is found, the URL and name tags for the metric are replaced with the new name.

Example usage

import { browser } from 'k6/browser';

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
};

export default async function () {
  const page = await browser.newPage();

  // Here, we set up an event listener using page.on('metric').
  // You can call page.on('metric') multiple times, and each callback function
  // will be executed in the order that page.on was called.
  page.on('metric', (metric) => {
    // Currently, metric.tag is the only available method on the metric object.
    // It enables matching on the URL tag using a specified regex pattern.
    // You can call metric.tag multiple times within the callback function.
    metric.tag({
      // This is the new name assigned to any metric that matches the defined
      // URL pattern below.
      name: 'test',
      // Provide one or more match patterns here. Any metrics that match a pattern
      // will use the new name specified above.
      matches: [
        // Each match pattern can include a URL and an optional method.
        // When a method is specified, the metric must match both the URL pattern
        // and the method. If no method is provided, the pattern will match all
        // HTTP methods.
        { url: /^https:\/\/test\.k6\.io\/\?q=[0-9a-z]+$/, method: 'GET' },
      ],
    });
  });

  try {
    // The following lines are for demonstration purposes.
    // Visiting URLs with different query parameters (q) to illustrate matching.
    await page.goto('https://test.k6.io/?q=abc123');
    await page.goto('https://test.k6.io/?q=def456');
  } finally {
    // Ensure the page is closed after testing.
    await page.close();
  }
}

`ControlOrMeta` support in the keyboard browser#1457

This approach enables tests to be written for all platforms, accommodating either Control or Meta for keyboard actions. For example, Control+click on Windows and Meta+clickon Mac to open a link in a new window.

Example usage

await page.keyboard.down('ControlOrMeta');

// Open the link in a new tab.
// Wait for the new page to be created.
const browserContext = browser.context();
const [newTab] = await Promise.all([
  browserContext.waitForEvent('page'),
  await page.locator('a[href="/my_messages.php"]').click(),
]);

await page.keyboard.up('ControlOrMeta');

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Since under the hood we do fully rely on the Golang’s SDK, our implementation doesn’t support zero salt lengths for the RSA-PSS sign/verify operations. ↩︎

Version 0.54.0 release notes

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

Version 0.54.0 release notes

k6 v0.54.0 is here 🎉! This release includes:

A new experimental CSV module
New k6 cloud commands for local execution and uploading script files
New ECMAScript features
Updated logo and branding

Breaking changes

#3913 changes the mapping of Golang’s math/big.Int type to bigint type in k6.
#3922 removes lib.Min and lib.Max from k6’s Go API, which could affect custom extensions that rely on these functions.
#3838 removes k6/experimental/timers - they are now available globally and no import is needed.
#3944 updates to k6/experimental/websockets, which makes the binaryType default value equal to "blob". With this change, k6/experimental/websockets is now compliant with the specification.

New features

Branding changes and logo `#3946`, `#3953`, `#3969`

As part of joining Grafana Labs in 2021, k6 was renamed to Grafana k6. The original k6 logo and branding was purple, which didn’t fit very well next to the Grafana Labs orange logo and all its other products.

In this release, we have a new logo in a new color, and the terminal banner has been redesigned to match the current branding more closely.

New experimental CSV module for efficient CSV data handling `#3743`

We’ve added a new experimental CSV module to k6 for more efficient and convenient CSV parsing and streaming, addressing the limitations of preexisting JavaScript-based solutions like papaparse.

What is it?

The CSV module offers two key features:

csv.parse(): This function parses a CSV file into a SharedArray at once using Go-based processing for faster parsing and lower memory usage compared to JavaScript alternatives.
csv.Parser: This class provides a streaming parser to read CSV files line-by-line, minimizing memory consumption and offering more control over parsing through a stream-like API. This is ideal for scenarios where memory optimization or fine-grained control of the parsing process is crucial.

Benefits for users

Faster Parsing: csv.parse bypasses most of the JavaScript runtime, offering significant speed improvements for large files.
Lower Memory Usage: Both solutions support shared memory across virtual users (VUs) with the fs.open function.
Flexibility: Choose between full-file parsing with csv.parse() or memory-efficient streaming with csv.Parser.

Tradeoffs

csv.Parse: Parses the entire file in the initialization phase of the test, which can increase startup time and memory usage for large files. Best suited for scenarios where performance is prioritized over memory consumption.
csv.Parser: Reads the file line-by-line, making it more memory-efficient but potentially slower due to reading overhead for each line. Ideal for scenarios where memory usage is a concern or where fine-grained control over parsing is needed.

Example usage

Expand to see an example of Parsing a full CSV file into a SharedArray.

import { open } from 'k6/experimental/fs';
import csv from 'k6/experimental/csv';
import { scenario } from 'k6/execution';

export const options = {
  iterations: 10,
};

let file;
let csvRecords;
(async function () {
  file = await open('data.csv');

  // The `csv.parse` function consumes the entire file at once, and returns
  // the parsed records as a SharedArray object.
  csvRecords = await csv.parse(file, { delimiter: ',' });
})();

export default async function () {
  // The csvRecords a SharedArray. Each element is a record from the CSV file, represented as an array
  // where each element is a field from the CSV record.
  //
  // Thus, `csvRecords[scenario.iterationInTest]` will give us the record for the current iteration.
  console.log(csvRecords[scenario.iterationInTest]);
}

Expand to see an example of streaming a CSV file line-by-line.

import { open } from 'k6/experimental/fs';
import csv from 'k6/experimental/csv';

export const options = {
  iterations: 10,
};

let file;
let parser;
(async function () {
  file = await open('data.csv');
  parser = new csv.Parser(file);
})();

export default async function () {
  // The parser `next` method attempts to read the next row from the CSV file.
  //
  // It returns an iterator-like object with a `done` property that indicates whether
  // there are more rows to read, and a `value` property that contains the row fields
  // as an array.
  const { done, value } = await parser.next();
  if (done) {
    throw new Error('No more rows to read');
  }

  // We expect the `value` property to be an array of strings, where each string is a field
  // from the CSV record.
  console.log(done, value);
}

New `k6 cloud run --local-execution` flag for local execution of cloud tests `#3904`, and #3931

This release introduces the --local-execution flag for the k6 cloud run command, allowing you to run test executions locally while sending metrics to Grafana Cloud k6.

k6 cloud run --local-execution script.js

By default, using the --local-execution flag uploads the test archive to Grafana Cloud k6. If you want to disable this upload, use the --no-archive-upload flag.

The --local-execution flag currently functions similarly to the k6 run -o cloud command, which is now considered deprecated (though it is not planned to be removed). Future updates will enhance --local-execution with additional capabilities that the k6 run -o cloud command does not offer.

New `k6 cloud upload` command for uploading test files to the cloud `#3906`

We continue to refine and improve the cloud service to improve how we handle uploading test files, so we’ve added a new k6 cloud upload command that replaces the k6 cloud --upload-only flag, which is now considered deprecated.

gRPC module updates driven by contributors

New `discardResponseMessage` option

#3877 and #3820 add a new option for the gRPC module discardResponseMessage, which allows users to discard the messages received from the server.

const resp = client.invoke('main.RouteGuide/GetFeature', req, { discardResponseMessage: true });

This reduces the amount of memory required and the amount of garbage collection, which reduces the load on the testing machine and can help produce more reliable test results.

Thank you, @lzakharov!

New argument `meta` for gRPC’s stream callbacks

#3801 adds a new argument meta to gRPC’s stream callback, which handles the timestamp of the original event (for example, when a message has been received).

let stream = new grpc.Stream(client, 'main.FeatureExplorer/ListFeatures');
stream.on('data', function (data, meta) {
  // will print the timestamp when message has been received
  call(meta.ts);
});

Thank you, @cchamplin!

Allow missing file descriptors for gRPC reflection

#3871 allows missing file descriptors for gRPC reflection.

Thank you, @Lordnibbler!

Sobek updates brings support of new ECMAScript features into k6 `#3899`, `#3925`, `#3913`

With this release, we’ve updated Sobek (the ECMAScript implementation in Go) which contains the new ECMAScript features that are now available in k6.

This includes support for numeric literal separators:

const billion = 1_000_000_000;

Support for BigInt, the values which are too large to be represented by the number primitive:

const huge = BigInt(9007199254740991);

Note: Before k6 version v0.54, Golang’s type math/big.Int mapped to another type, so this might be a breaking change for some extensions or users.

RegExp dotAll support, where you can match newline characters with .:

const str1 = 'bar\nexample foo example';

const regex1 = /bar.example/s;

console.log(regex1.dotAll); // true

Support for ES2023 Array methods: with, toSpliced, toReversed and toSorted.

Thank you @shiroyk for adding both the new array methods and BitInt :bow:.

New `setChecked` method for the browser module `browser#1403`

Previously, users could check or uncheck checkbox and radio button elements using the check and uncheck methods. Now, we’ve added a setChecked method that allows users to set a checkbox or radio button to either the checked or unchecked state with a single method and a boolean argument.

await page.setChecked('#checkbox', true); // check the checkbox
await page.setChecked('#checkbox', false); // uncheck the checkbox

Page, Frame, ElementHandle, and Locator now support the new setChecked method.

Async `check` function utility `k6-utils#13`

Writing concise code can be difficult when using the k6 check function with async code since it doesn’t support async APIs. A solution that we have suggested so far is to declare a temporary variable, wait for the value that is to be checked, and then check the result later. However, this approach can clutter the code with single-use declarations and unnecessary variable names, for example:

const checked = await p.locator('.checked').isChecked();

check(checked, {
  checked: (c) => c,
});

To address this limitation, we’ve added a version of the check function to jslib.k6.io that makes working with async/await simpler. The check function is a drop-in replacement for the built-in check, with added support for async code. Any Promises will be awaited, and the result is reported once the operation has been completed:

// Import the new check function from jslib.k6.io/k6-utils
import { check } from 'https://jslib.k6.io/k6-utils/1.5.0/index.js';

// ...

// Use the new check function with async code
check(page, {
  checked: async (p) => p.locator('.checked').isChecked(),
});

Check out the check utility function’s documentation for more information on how to use it.

`k6/experimnetal/websockets` updates towards WebSockets API compatibility

Support ArrayBufferViews in `send` for `k6/experimental/websockets` #3944

As part of making k6/experimental/websockets compliant with the WebSocket API, it now supports Uint8Array and other ArrayBufferViews directly as arguments to send, instead of having to specifically provide their buffer.

This should make the module more compliant with libraries that use the WebSocket API.

Thanks to @pixeldrew for reporting this. :bow:

`readyState` actually being a number #3972

Due to goja/Sobek internal workings, readyState wasn’t exactly a number in JavaScript code. This had some abnormal behavior, which limited interoperability with libraries.

This has been fixed, and readyState is a regular number from the JavaScript perspective.

Thanks to @dougw-bc for reporting this. :bow:

Rework of how usage is being collected internally and additional counters `#3917` and `#3951`

As part of working on k6 over the years, we have often wondered if users use certain features or if they see a strange corner case behavior.

We have usually made guesses or tried to extrapolate from experience on issues we see. Unfortunately, this isn’t always easy or possible, and it’s definitely very skewed. As such, we usually also add warning messages to things we intend to break to inform people and ask them to report problems. But we usually see very little activity, especially before we make changes.

This also only works for things we want to remove, and it doesn’t help us know if people use new functionality at all or if there are patterns we don’t expect.

While k6 has been collecting usage for a while, they’re surface-level things, such as how many VUs were run, the k6 version, or which internal modules were loaded. The system for this was also very rigid, requiring a lot of work to add simple things, such as if someone used the require function.

This process has been reworked to make things easier, and a few new usage reports have been added:

When Grafana Cloud is used, it will also tell us which test run it is. We already have most of the information reported through metrics and from the test being executed in the cloud. But this will help us filter cloud test runs from local runs and potentially warn cloud users if they’re using experimental modules that will be removed.
The number of files parsed, as well as the number of .ts files parsed. This will help us understand if people use small or big projects and if TypeScript support is being used.
Usage of require. Now that we have ESM native support, using require and CommonJS adds complexity. It’s interesting to us whether removing this in the future - likely years, given its support in other runtimes, is feasible.
Usage of global. This will help us decide if we can drop compatibility-mode differences or even the whole concept.

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Version 0.53.0 release notes

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

Version 0.53.0 release notes

k6 v0.53.0 is here 🎉! This release includes:

Native ECMAScript modules support
New experimental OpenTelemetry metrics output
Blob support in experimental websockets module
Consolidate cloud features and commands under k6 cloud
Breaking change: remove magic URL resolutions

Breaking changes

Require is now specification compliant and always resolves based on the file it is written in #3534

The require function in k6 used to resolve identifiers based on the current “root of execution” (more on that later). In a lot of cases, that aligns with the file the require is written in or a file in the same folder, which leads to the same result. In a small subset of cases, this isn’t the case.

In every other implementation, and more or less by the CommonJS specification, require should always be relative to the file it is written in.

This also aligns with how ESM and dynamic import also work. In order to align with them require now uses the same underlying implementation.

There was a warning message for the last 2 releases trying to tease out cases where that would be problematic.

"root of execution" explanation

This is very much an implementation detail that has leaked and likely a not intended one.

Whenever a file is require-ed it becomes the “root of execution”, and both require and open become relative to it. Once the require finishes, the previous “root of execution” gets restored. Outside of the init context execution, the main file is the “root of execution”.

Example:

Have 3 files: main.js

const s = require('./A/a.js');
if (s() != 5) {
  throw 'Bad';
}
module.exports.default = () => {}; // just for k6 to not error

/A/a.js:

module.exports = function () {
  return require('./b.js');
};

/A/b.js

module.exports = 5;

In this example when require is called in /A/a.js the main.js is once again the “root of execution”. If you call the function in /A/a.js just after defining it though, it will work as expected.

You can use the newly added import.meta.resolve() function if you want to create a path that is relevant to the currently calling module. That will let you call it outside of a helper class and provide the path to it. Refer to docs for more details.

As part of the ESM native support implementation, two common broken patterns in the ecosystem became apparent.

One is arguably a developer experience improvement, and the other is a consequence of the previous implementation.

Mixing CommonJS and ESM

Previously, k6 used a transpiler (Babel) internally to transpile ESM syntax to CommonJS. That led to all code always being CommonJS, and if you had CommonJS next to it, Babel would not complain.

As k6 (or the underlying JS VM implementation) did not understand ESM in itself and that CommonJS is a 100% during execution feature, this was not easy to detect or prevent.

We added a warning in v0.52.0 to give users time for migration.

To fix this - all you need is to stick to either CommonJS or ESM within each file.

Code examples and proposed changes

import { sleep } from "k6";

module.exports.default = func() { ...}

In the example above both ESM and CommonJS are used in the same file.

You can either replace:

module.exports.default = func() {}

With the ESM syntax:

export default func() {}

Or replace:

import { sleep } from 'k6';

With CommonJS:

const sleep = require('k6').sleep;

Imported identifier that can’t be resolved are now errors

Previous to this, if you were using the ESM syntax and imported the foo identifier, but the exporting file didn’t export it, there wouldn’t be an error.

bar.js:

export const notfoo = 5;

main.js

import { foo } from './bar.js';
export default function () {
  foo.bar(); // throws exception here
}

The example would not error out, but when it is accessed, there would be an exception as foo would be undefined.

With native ESM support, that is an error as defined by the specification and will occur sooner.

This arguably improves UX/DX, but we have reports that some users have imports like this but do not use them. So, they wouldn’t be getting exceptions, but they would now get errors.

The solution, in this case, is to stop importing the not exported identifiers.

No more “magic” URL resolution

For a long time, k6 has supported special magic URLs that aren’t really that.

Those were URLs without a scheme that:

Started with github.com, and if pasted to a browser won’t open to a file. Their appeal was that you can more easily write them by hand if you know the path within a GitHub repo.
Started with cdnjs.com, and if pasted to a browser will open a web page with all the versions of the library. The appeal here is that you will get the latest version.

Both of them had problems though.

The GitHub ones seemed to have never been used by users, likely because you need to guess what the path should look like, and you can always just go get a real URL to the raw file.

While the cdnjs ones have some more usage, they are both a lot more complicated to support, as they require multiple requests to figure out what needs to be loaded. They also change over time. In addition the only known use at the moment is based on a very old example from an issue and it is even pointing to concrete, old version, of a library.

Given that this can be done with a normal URL, we have decided to drop support for this and have warned users for the last couple of versions.

Deprecated `k6/experimental/tracing` in favor of a JavaScript implementation

k6/experimental/tracing is arguably not very well named, and there is a good chance we would like to use the name for actual trace and span support within k6 in the future.

On top of that it can now be fully supported in js code, which is why http-instrumentation-tempo was created.

The JavaScript implementation is a drop-in replacement, so all you need to do is replace k6/experimental/tracing with https://jslib.k6.io/http-instrumentation-tempo/1.0.0/index.js.

The module is planned to be removed in v0.55.0, planned for November 11th, 2024.

Experimental websockets now require `binaryType` to be set to receive binary messages

As part of the stabilization of the k6/experimental/websockets we need to move the default value of binaryType to blob. It was previously arraybuffer and since the last version there was a warning that it needs to be set in order for binary messages to be received.

That warning is now an error.

In the future we will move the default value to blob and remove the error.

New features

The new features include:

Native ESM support, which also brings some quality of life JavaScript features
Blob support in the experimental websockets module
Experimental OpenTelemetry metrics output
Consolidating cloud related commands and features under k6 cloud

Native ESM support #3456

With this feature k6 is now ES6+ compliant natively. Which means (asterisk free) support for the spread operator with object, private class fields and optional chaining

But also faster startup times, more consistent errors and easier addition of features as we now only need to add them to Sobek instead of also them being supported in the internal Babel.

History of compatibility mode and ECMAScript specification compliance

Some history: More than 6 years ago k6 started using core-js and babel to get ES6+ features. core-js is a implementation of a lot of the types and their features such as String.prototype.matchAll among other things, and Babel gets one piece of code that uses some syntax and returns a piece of code doing the same thing (mostly) but with different syntax. Usually with the idea of supporting newer syntax but returning code that can run on runtimes which only support old syntax.

This is great, but it means that:

For core-js each VU needs to run a bunch of JS code each initialization so it can polyfill everything that is missing
Babel needs to be parsed and loaded and then given files to transpile on each start.

Both of those aren’t that big problems usually, but the runtime k6 uses is fairly fast, but isn’t V8. What it lacks in speed it gets back in being easy to interact with from Go, the language k6 is written in.

But it means that now on each start it needs to do a bunch of work that adds up.

So long time ago for people who would want to not have to do this we added compatibility-mode=base. This allowed you to potentially not use this features and get a big speedup. Or use them outside of k6 and likely still get significant speed up if you cut down on it.

At the same time the author and maintainer of the JS runtime we used (goja) did implement a big portion of what we were missing from core-js and also Babel. After some experiments to cut down the core-js we import we ended up contributing back the remaining parts and dropping the whole library. Which lead to 5 times reduction of memory per VU for simple scripts. And even for fairly complicated ones.

With this in mind we did try to cut down Babel as well and contribute back the simpler things it was used for. This over the years lead to small pieces of what Babel did being moved to goja and then disabled in Babel. Some of those were just easy wins, some of those were things that had very bad pathological cases where using a particular syntax made transpilation times explode.

In all of that work there always were small (or not so small) breaking changes due to many factors - sometimes our new implementation was slightly wrong and we needed to fix, sometimes more than what was in the standard was enabled in core-js or Babel, sometimes the standard changed on those. And sometimes the implementation in Babel or core-js wasn’t as full and didn’t account for all corner cases.

ECMAScript Modules(ESM) is the last such feature that Babel was used for. It also happens to be likely the one most people used, due to the fact that it is the standard way to reuse code and import libraries.

While the work on this feature started over 2 years ago, it both depended on other features that weren’t there yet, but also interacts with more or less every other feature that is part of the ECMAScript standard.

Along the way there were many internal refactors as well as additional tests to make certain we can be as backwards compatible as possible. But there also ended up being things that just weren’t going to be compatible, like the listed breaking changes.

After ESM now being natively supported, compatibility-mode base vs extended has only 1 feature difference - aliasing global to globalThis to make it a bit more compatible with (old) Node.js. There is ongoing discussion if that as well should be removed.

For the purposes of having less intrusive changes and shipping this earlier a few things have not been implemented in k6. That includes top-level-await and dynamic import support. Both of them are likely to land in the next version.

`import.meta.resolve()` gets an URL from a relative path the same way `import` or `require` does #3873

As part of the move to ESM a lot of cases where k6 currently do not resolve the same relative path to the same file were found. Some of those were fixed - as those in require, but others haven’t.

It also became apparent some users do use the relativity of require, but also open. As we move to make this consistent among uses, we decided to let users have a better transition path forward.

Using import.meta.resolve will give you just a new URL that can be used in all functions and it will give you the same result.

import.meta.resolve uses the same algorithm and relativity as ESM import syntax. Refer to docs for more details.

Blob support in the experimental websockets module grafana/xk6-websockets#74

In order to support the default WebSocket.binaryType type as per spec ("blob"), we have added support for the Blob interface as part of the features included in the xk6-websockets module.

So, from now on it can be used with import { Blob } from "k6/experimental/websockets";. In the future, apart from graduating this module to stable, we might also want to expose the Blob interface globally (no imports will be required). But for now, please remind that its support is still experimental, as the entire module is. Refer to the docs for more details.

Experimental OpenTelemetry Output #3834

This release introduces a new experimental output for OpenTelemetry. This allows users to send k6 metrics to any OpenTelemetry-compatible backends. More details and usage examples can be found in the documentation.

To output metrics to OpenTelemetry, use the experimental-opentelemetry output option:

 k6 run -o experimental-opentelemetry examples/script.js

If you have any feedback or issues, please let us know directly in the extension repository.

Consolidating cloud features under `k6 cloud` #3813

This release introduces the first iteration of the revamped cloud-related commands under the k6 cloud command, featuring two new subcommands:

k6 cloud login: replaces k6 login cloud for authenticating with the cloud service. It supports token-based authentication only. The previous authentication method using email and password will still be available through the legacy k6 login cloud command, which is now deprecated and will be removed in a future release (no removal date set yet).
k6 cloud run: is the new official way to run k6 on the cloud service, serving as an alternative to the existing k6 cloud command. The k6 cloud command will remain available for a few more versions but will eventually function only as a wrapper for all cloud-related commands, without any direct functionality.

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Version 0.52.0 release notes

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

Version 0.52.0 release notes

k6 v0.52.0 is here 🎉! Some special mentions included in this release:

We’ve switched to our own fork of goja named sobek.
Panics are no longer captured.
We’ve added experimental support for TypeScript and ES6+.
k6/browser has graduated from an experimental module, and now has a fully Async API.

Breaking changes

Switch `goja` to our own fork named `sobek` #3775

To accelerate the development speed and bring ECMAScript Modules (ESM) support to k6 earlier (https://github.com/grafana/k6/issues/3265), we have decided to create a fork of the goja project under the Grafana GitHub organization, named sobek.

Starting on this release, k6 (and its extensions) now use sobek instead of the original goja, for all (of the publicly exposed parts of the API) except for a couple of packages that are only used internally by k6.

All k6 extensions linked in the docs have had a PR for this transition opened, as explained in this comment. Any extension author who hasn’t gotten a PR can follow the same steps.

Find further details in #3772 and #3773.

Panics are no longer being captured #3777

Since this release, Go panics are no longer being captured by k6. This means that if a panic occurs while running a test, the k6 process will crash, and the panic stack trace will be printed to the console.

We decided to change this behavior because it’s something that was left from the past as a safeguard, but it’s not as good as it might seem. For most cases with multiple goroutines/async, it’s not enough and also makes a bunch of potential bugs seem like less of an issue.

Thus, this will help us to identify and fix bugs earlier, improve the overall stability of k6, and most likely make the experience of developing k6 extensions friendlier.

`lib.State` no longer has `Group` #3750

As the result of refactoring the implementation of group and check methods, in order to decouple them, and thus enable other future improvements, the lib.State object no longer has a Group field.

This change should not affect most users, except for a couple of extensions, for which the use of Group was already questionable:

xk6-fasthttp
xk6-g0

Other breaking changes

#3797 starts using - as a special value for --archive-out to output the archive to stdout.
browser#1318 makes the Mouse.up and Mouse.down methods no longer take x and y coordinates. Instead, they dispatch events on the current mouse position.

New features

Experimental support for TypeScript and ES6+ using esbuild #3738

This release of k6 introduces experimental support for TypeScript and ES6+ using esbuild, thanks to a new compatibility mode named experimental_enhanced.

k6 run --compatibility-mode=experimental_enhanced script.js

With this new compatibility mode, the test source code is transformed using esbuild instead of Babel, which also means that source files with the extension ".ts" are loaded by esbuild’s TypeScript loader, which results in partial TypeScript support: it removes the type information but doesn’t provide type safety.

`k6/browser` has graduated from an experimental module #3793

The browser module is now available as k6/browser instead of k6/experimental/browser. The previous k6/experimental/browser module will be removed on September 23rd, 2024. Refer to the migration guide for more information on how to update your scripts.

`k6/browser` has now a fully Async API browser#428

This release introduces a fully Async API for the k6/browser module. This means that nearly all the methods in the module now return promises. This change is part of the ongoing effort to make the browser module more user-friendly and easier to use. Please see the browser documentation for more information on how to use the new Async API.

Related Changes:

browser#1310, browser#1311, browser#1312, browser#1316, browser#1328, browser#1337, browser#1367, browser#1366, browser#1314, browser#1332, browser#1323, browser#1355, browser#1348, browser#1364 Migrates Browser, BrowserContext, ElementHandle, Frame, JSHandle, Keyboard, Locator, Mouse, Page, Request, Response APIs to async.

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Version 0.51.0 release notes

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

Version 0.51.0 release notes

k6 v0.51.0 is here 🎉! Some special mentions included in this release:

Breaking changes

Transition browser APIs to Async

In the last release notes we mentioned this breaking change, and we wanted to remind and update you on the plan. In the next release (v0.52.0), most of the synchronous browser APIs will be migrated to be asynchronous (promisifying them). We expect this will affect most if not all of our users.

This breaking change will require you to add await in front of most of the browser module APIs. Without this await you will witness undocumented and unknown behavior during the runtime. To make the migration simpler we advise that you work with the latest k6 type definitions.

You can find a list of all the APIs that we expect to convert to async in a comment in issue browser#428.

Awaiting on something that’s not a thenable just returns that value, which means you can add the await keyword today on the APIs that will become async to future proof your test scripts.

Here are the reasons for making this large breaking change:

Most browser APIs use some form of long-running IO operation (networking) to perform the requested action on the web browser against the website under test. We need to avoid blocking JavaScript’s runtime event loop for such operations.
We’re going to add more asynchronous event-based APIs (such as page.on) that our current synchronous APIs would block.
To align with how developers expect to work with JavaScript APIs.
To have better compatibility with Playwright.

As a starting point, we have migrated a single API (the tap method), which you can find the details below that will help visualize the upcoming breaking changes.

Browser `Tap` is now an async method grafana/xk6-browser#1268

This release converts the Tap method in the browser module into an asynchronous method. This change is necessary to ensure that the method can be used in async contexts and to align with the rest of the browser module’s planned asynchronous API. To use the Tap method, you must now add the await keyword before the method call.

Affected components:

See the following example for how to use the Tap method after this change:

Before:

import browser from 'k6/experimental/browser';

// ...

export default function () {
  // ...
  page.tap(selector, { modifiers: ['Alt', 'Control', 'Meta', 'Shift'] });
  // ...
}

After:

import browser from 'k6/experimental/browser'

// ...

export default function () {
	// ...
	await page.tap(selector, { modifiers: ["Alt", "Control", "Meta", "Shift"] });
	// ...
}

`k6/experimental/websockets` will not default `binaryType` to `“arraybuffer”'

As part of the stabilization of the API it needs to become as close to the specification.

Early in the development the idea of adding Blob support as part was deemed feature creep and was dropped in favor of going with only "arraybuffer". But the specification defaults to returning binary responses as Blob - which was another thing that was changed.

While adding Blob is still on our radar, moving the default is always going to be a breaking change that we need to do to align with the specification.

For this release there is now a warning that will be printed if binaryType is not set to "arraybuffer" and a binary response is received. The warning will go away when binaryType is set to "arraybuffer".

In the next release the warning will become an error.

More info and place for discussion can be found in an this issue.

`k6/experimental/grpc` is no longer available #3530

As the last step of the graduation process for the experimental gRPC module, we completely removed the module. It is now fully integrated into the stable k6/net/grpc module. So, if you haven’t done this yet, replace your imports from k6/experimental/grpc to k6/net/grpc.

Deprecations

The following pull requests start the process to introduce breaking changes. They are currently starting to emit warning if their condition is hit, but they will turn to return errors in the future release. It is recommended to use the suggested alternative, or to fix the script if you see the warning message.

#3681 Use of not-compliant require expressions.
#3680 Modules resolution of modules not previously seen during the initialization phase.
#3676 Working directory is set to the current location when the script is provided using stdin, instead of the root folder.
#3530 Automagically resolve modules from cdnjs and github “URLs”.

New features

Introduction of `k6/experimental/streams` module #3696

This release of k6 introduces the new k6/experimental/streams module, which partially supports the JavaScript Streams API, focusing initially on the ReadableStream construct.

With the ReadableStream, users can define and consume data streams within k6 scripts. This is particularly useful for efficiently handling large datasets or for processing data sequentially in a controlled flow.

Expand to see an example of stream's usage

The following example demonstrates creating and consuming a simple stream that emits numbers until it reaches a predefined limit:

import { ReadableStream } from 'k6/experimental/streams';

function numbersStream() {
  let currentNumber = 0;

  return new ReadableStream({
    start(controller) {
      const fn = () => {
        if (currentNumber < 5) {
          controller.enqueue(++currentNumber);
          setTimeout(fn, 1000);
          return;
        }

        controller.close();
      };
      setTimeout(fn, 1000);
    },
  });
}

export default async function () {
  const stream = numbersStream();
  const reader = stream.getReader();

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    console.log(`received number ${value} from stream`);
  }

  console.log('we are done');
}

For more advanced examples, please head to the MDN Web Docs on the Streams API.

Limitations

Currently, users can define and consume readable streams. However, this release does not include support for byte readers and controllers, nor does it include support the tee, pipeTo, and pipeThrough methods of the ReadableStream object.

New features and updates of WebCrypto API support #3714

This release brings support for asymmetric cryptography to the k6/experimental/webcrypto module. We added support of the elliptic curves algorithms ECDH (xk6-webcrypto#67) and ECDSA (xk6-webcrypto#69) algorithms along with new import/export key formats like spki and pkcs8.

One of the newly added operations is deriveBits, which allows parties to generate a unique shared secret by using shared public and non-shared private keys.

Expand to see an example of generating a shared secret for Alice and Bob.

import { crypto } from 'k6/experimental/webcrypto';

export default async function () {
  // Generate a key pair for Alice
  const aliceKeyPair = await crypto.subtle.generateKey(
    {
      name: 'ECDH',
      namedCurve: 'P-256',
    },
    true,
    ['deriveKey', 'deriveBits']
  );

  // Generate a key pair for Bob
  const bobKeyPair = await crypto.subtle.generateKey(
    {
      name: 'ECDH',
      namedCurve: 'P-256',
    },
    true,
    ['deriveKey', 'deriveBits']
  );

  // Derive shared secret for Alice
  const aliceSharedSecret = await deriveSharedSecret(aliceKeyPair.privateKey, bobKeyPair.publicKey);

  // Derive shared secret for Bob
  const bobSharedSecret = await deriveSharedSecret(bobKeyPair.privateKey, aliceKeyPair.publicKey);

  // alice shared secret and bob shared secret should be the same
  console.log('alice shared secret: ' + printArrayBuffer(aliceSharedSecret));
  console.log('bob shared secret: ' + printArrayBuffer(bobSharedSecret));
}

async function deriveSharedSecret(privateKey, publicKey) {
  return crypto.subtle.deriveBits(
    {
      name: 'ECDH',
      public: publicKey,
    },
    privateKey,
    256
  );
}

const printArrayBuffer = (buffer) => {
  const view = new Uint8Array(buffer);
  return Array.from(view);
};

The sign and verify operations got support for ECDSA algorithm. The sign operation allows you to sign a message with a private key, while the verify operation allows you to verify the signature with a public key.

Other notable updates and fixes:

xk6-webcrypto#68 fixes a degradation for the sign/verify operations for HMAC algorithm.
xk6-webcrypto#75, xk6-webcrypto#76 refactor webcrypto module to be thread-safe.
xk6-webcrypto#74 adds JWK import/export support for ECDH and ECDSA. Refactors JWK import/export to use only go standard library.

See webcrypto’s module documentation for more details.

Timers globally available #3589

setTimeout, setInterval and related clear functions have been part of the JavaScript ecosystem, probably for as long as it has existed.

In the previous releases we stabilized and made them available through k6/timers module. While the module isn’t going anywhere and might get more identifiers, setTimeout is usually used without importing it. For this reason it is now globally available along clearTimeout, setInterval and clearInterval.

No code needs to be changed, but you no longer need to import k6/timers to use this functionality.

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Version 0.50.0 release notes

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

Version 0.50.0 release notes

k6 v0.50.0 is here 🎉!

This release:

Adds support for uploading files from the browser module.
Introduces the options.cloud option.
Stabilizes the previously experimental timers module as the k6/timers module.
Brings JSON Web Key support to the k6/experimental/webcrypto module.

Breaking changes

websockets#60 allows manually setting the name tag, which also overwrites the url tag with the name value. This change makes it consistent with the logic that was implemented in k6 v0.41. Thanks, @mkadirtan for contributing!

Browser APIs to Async

In future releases, we are going to be moving most of the synchronous browser APIs to asynchronous ones (promisifying them). We expect this will affect most of our users, so we are posting this upfront before making the change. Here are the reasons for making this large breaking change:

Most browser APIs use some form of long-running IO operation (networking) to perform the requested action on the web browser against the website under test. We need to avoid blocking JavaScript’s runtime event loop for such operations.
We’re going to add more asynchronous event-based APIs (such as page.on) that our current synchronous APIs would block.
To align with how developers expect to work with JavaScript APIs.
To have better compatibility with Playwright.

You can find a list of all the APIs that we expect to convert to async in a comment in issue browser#428.

Awaiting on something that’s not a thenable just returns that value, which means you can add the await keyword against APIs that will become async to future proof your test scripts.

New features

Add support for uploading files from the browser module browser#1097, browser#1244

You can now upload files using the available input forms on the website under test. The new API is setInputFiles which can be called from a page, frame or elementHandle types. It can upload one or more files encoded in the test script. To upload files from the local file system, work with the experimental fs module.

Expand to see the examples.

For the following examples, we will use the HTML file:

<html>
  <body>
    <form method="POST" action="/upload" enctype="multipart/form-data">
      <input type="file" name="upl" id="upload" multiple />
      <input type="submit" value="Send" />
    </form>
  </body>
</html>

Uploading a file can be achieved with the following script:

// Import the k6 encoder module.
import encoding from 'k6/encoding';
...
export default async function () {
  const page = browser.newPage();

  await page.goto(url)

  // Encode and upload some data into a plain text file called test.txt.
  page.setInputFiles('input[id="upload"]', { name: 'test.txt', mimetype: 'text/plain', buffer: encoding.b64encode('Hello World') })

  // Click on the submit button on the form to upload the file.
  const submitButton = page.locator('input[type="submit"]')
  await Promise.all([page.waitForNavigation(), submitButton.click()])

  page.close();
}

Uploading multiple files can be done with the use of an array:

page.setInputFiles('input[id="upload"]', [
  { name: 'test.txt', mimetype: 'text/plain', buffer: encoding.b64encode('Hello World') },
  {
    name: 'test.json',
    mimetype: 'text/json',
    buffer: encoding.b64encode('{"message": "Hello World"}'),
  },
]);

Thanks to @bandorko! :bow: :tada:

Introducing options.cloud #3348, #3407

In this release, we introduce a new way of defining cloud options. From now on, you can use options.cloud instead of options.ext.loadimpact.

To migrate, you can move the loadimpact object to the root of the options object and rename it to cloud. For example:

export let options = {
  ext: {
    loadimpact: {
      name: 'Legacy way of defining cloud options',
      projectID: 12345,
    },
  },
};

export let options = {
  cloud: {
    name: 'Current way of defining cloud options',
    projectID: 12345,
  },
};

All scripts with legacy options.ext.loadimpact will continue to function as before. There’s no planned sunset date for the legacy option, but we highly encourage using options.cloud going forward. For more details about cloud options, refer to Cloud options.

Timers API becomes part of the k6 core #3587

With this release, the timers API is no longer experimental and can be imported as k6/timers instead of as k6/experimental/timers. The later will be supported until v0.52.0.

You can also contribute to the discussion on making the current timer exports globally available in #3589, or just give it a :+1:.

JSON Web Key support in `k6/experimental/webcrypto` module webcrypto#61

The experimental webcrypto module now supports the JSON Web Key (JWK) format, using the importKey and exportKey methods.

This allows you to import and export keys in the JWK format for the supported algorithms.

const generatedKey = await crypto.subtle.generateKey({ name: 'AES-CBC', length: '256' }, true, [
  'encrypt',
  'decrypt',
]);

const exportedKey = await crypto.subtle.exportKey('jwk', generatedKey);

UX improvements and enhancements

browser#1197, browser#1202, browser#1203, browser#1221 adds the ability to upload screenshots to a remote location.
browser#1209 adds a shadow DOM usage example.
browser#1233 returns actionable errors for evaluate APIs.
browser#1228, browser#1232, browser#1235 injects the testRunId into the window.k6 object for external applications to query (for example, Grafana Faro).

Browser Context Isolation browser#1112

With this release, we have overhauled and (tremendously) improved the performance and stability of the browser module. It’s now possible to run tests with a larger number of VUs concurrently without any performance issues. Previously, when running tests with multiple VUs concurrently, each VU’s browser context would attach to the pages from the other VUs’ browser contexts. This led to unexpected behavior and performance issues and, to an extent, reduced the module’s capability to run multi-VU tests.

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Version 0.49.0 release notes

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

Version 0.49.0 release notes

k6 v0.49.0 is here 🎉! This release:

Adds a built-in web dashboard that displays test results in real time.
Introduces clear functionality to the browser module’s locator classes.
Merges the gRPC experimental module back into the gRPC core module.
Enables the ability to get the selection from an element in k6/html.
Collects internal modules and outputs used by a script.
Prepares k6/experimental/timers for stabilization.

Breaking changes

#3494 stops updating loadimpact/k6 docker image. If you still use it, please migrate to the grafana/k6 image.
browser#1111 removes timeout option for isVisible and isHidden since the API no longer waits for the element to appear on the page.

New features

Web Dashboard

The new web dashboard brings real-time visualization to load testing. This feature allows users to monitor test progress and analyze results dynamically, enhancing the overall testing experience.

Real-time test results

Activate this feature using the environment variable K6_WEB_DASHBOARD=true. For this initial release, the dashboard is not enabled by default to allow users to opt into this new experience as it evolves.

K6_WEB_DASHBOARD=true k6 run script.js

Once enabled and the test script is running, navigate to http://localhost:5665 in your web browser to access the dashboard.

Test report

The web dashboard also offers an HTML test report (see an example) for detailed analysis, enabling easy sharing and downloading capabilities for collaboration.

To access and download the report, click on the Report button in the dashboard’s top right corner or use the K6_WEB_DASHBOARD_EXPORT environment variable.

K6_WEB_DASHBOARD=true K6_WEB_DASHBOARD_EXPORT=test-report.html k6 run script.js

Add `clear` to the `locator` class browser#1149

The new clear method on the locator class clears the text boxes and input fields. This is useful when navigating to a website where the text boxes and input fields already contain a value that needs to be cleared before filling it with a specific value.

Expand to see an example of the new functionality.

import { check } from 'k6';
import { browser } from 'k6/experimental/browser';

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
};

export default async function () {
  const context = browser.newContext();
  const page = context.newPage();

  await page.goto('https://test.k6.io/my_messages.php', { waitUntil: 'networkidle' });

  // To mimic an input field with existing text.
  page.locator('input[name="login"]').type('admin');

  check(page, {
    not_empty: (p) => p.locator('input[name="login"]').inputValue() != '',
  });

  // Clear the text.
  page.locator('input[name="login"]').clear();

  check(page, {
    empty: (p) => p.locator('input[name="login"]').inputValue() == '',
  });

  page.close();
}

Add tracing to the browser module browser#1100

The browser module now generates traces that provide a representation of its inner workings, such as API methods executed (for example browser.newPage and page.goto), page navigations, and Web Vitals measurements.

Currently, the instrumented methods are a subset of all the methods exposed by the browser module API, but this will be extended in the future.

The traces generation for the browser module depends on the overall k6 traces option introduced in v0.48.0. Check out the documentation to learn more about it.

gRPC streaming API becomes part of the k6 core #3490

With this release, gRPC’s streaming API becomes part of the core’s k6/net/grpc module. The experimental k6/experimental/grpc has been back-merged into the core.

You can still use import k6/experimental/grpc for a couple of releases, but it’s deprecated and will be removed in the future (planned in k6 version v0.51.0).

To migrate your scripts, replace k6/experimental/grpc with k6/net/grpc in your script imports, and the code should work as before.

k6/html: Extract selection from element #3519

k6/html has been around for a while and allows you to search within an HTML document with a jQuery-like API called Selection, and also has support for the more standard Element that represents DOM element.

For a long time, you could get an Element from a Selection using the .get(index), but you couldn’t get back to a Selection from an Element.

This is not a common case, but one that requires quite a bit of code. For example, see the following jQuery snippet:

let li = http.get('https://test.k6.io').html().find('li');
li.each(function (_, element) {
  // here element is an element not a selection
  // but what if for each li we want to select something more?
  // in jquery that will be:
  let container = $(element).closest('ul.header-icons');
  // but what should `$` do?
  // in a browser there is only 1 html document that you have access to
  // in k6 though you can be working with multiple ones, so `$` can't know which one it should
  // work against
});

In order to support the above example, you can use selection, without going to the element:

let li = http.get('https://test.k6.io').html().find('li');
for (; li.size() > 0; li = li.next()) {
  let ul = li.closest('ul.header-icons'); // li here is still a selection and we iterate over it.
}

This is not always possible though, and arguably isn’t what most users will naturally do.

Because of this, we have now added a new .selection() which returns a selection for its element.

let li = http.get('https://test.k6.io').html().find('li');
li.each(function (_, element) {
  let container = element.selection().closest('ul.header-icons');
  // .. more code
});

Thanks to @Azhovan! :bow: :tada:

Collect usage data on imported internal modules and outputs #3525

k6 now collects usage data of the modules and outputs that are being used when the usage report is enabled. The data collection is only related to the built-in k6 modules and outputs. Private, custom modules and extensions are never collected. The usage report is enabled by default in k6, but it is possible to opt-out using the no-usage-report option.

We always want to improve the product, but at the same time, we need to pay attention to where we allocate our resources. Having data of what are the most used modules and outputs gives us better confidence to make decisions because we are supported by data. The data can let us know what percentage of our users will benefit from the introduction of a new feature and also, how many of them would be impacted in case of a breaking change.

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Version 0.48.0 release notes

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

Version 0.48.0 release notes

k6 v0.48.0 is here 🎉! This release includes:

Numerous long-awaited breaking changes.
A new k6 new subcommand to generate a new test script.
A new k6/experimental/fs module for file interactions.
CPU and network throttling support for the k6 browser module.

Breaking changes

This release includes several breaking changes, mainly cleaning up deprecations from previous versions. They should have a straightforward migration process, and not heavily impact existing users.

#3448 limits metric names, aligning to both OpenTelemetry (OTEL) and Prometheus name requirements, while still being limited to 128 ASCII characters. Warnings about the limit started in v0.45.
#3439 changes the Client signature in k6/experimental/redis module. Refer to the module-related section below.
#3350 removes the grpc.invoke()’s parameter headers, deprecated in k6 v0.37. Use the metadata parameter instead.
#3389 removes the --logformat flag, deprecated in v0.38. Use the --log-format flag instead.
#3390 removes all CSV output’s CLI arguments, deprecated in v0.35. This change makes the CSV output consistent with other output formats.
#3365 removes the k6 convert CLI command, deprecated in v0.41. Use the har-to-k6 package instead.
#3451 removes logic that would attempt to prepend a https:// scheme to module specifiers that were not recognized. Deprecated in k6 v0.25. Use full URLs if you want to load remote modules instead.

New features

Add `k6 new` subcommand #3394

k6 now has a new subcommand that generates a new test script. This is useful for new users who want to get started quickly, or for experienced users who want to save time when creating new test scripts. To use the subcommand, open your terminal and type:

k6 new [filename]

If no filename is provided, k6 uses script.js as the default filename. The subcommand will create a new file with the provided name in the current directory, and populate it with a basic test script that can be run with k6 run.

Add a `k6/experimental/fs` module #3165

k6 now has a new k6/experimenal/fs module providing a memory-efficient way to handle file interactions within your test scripts. It currently offers support for opening files, reading their content, seeking through it, and retrieving metadata about them.

Unlike the traditional open function, which loads a file multiple times into memory, the filesystem module reduces memory usage by loading the file as little as possible, and sharing the same memory space between all VUs. This approach significantly reduces the memory footprint of your test script and lets you load and process large files without running out of memory.

For more information, refer to the module documentation.

Expand to see an example of the new functionality.

This example shows the new module usage:

import fs from 'k6/experimental/fs';

// k6 doesn't support async in the init context. We use a top-level async function for `await`.
//
// Each Virtual User gets its own `file` copy.
// So, operations like `seek` or `read` won't impact other VUs.
let file;
(async function () {
  file = await open('bonjour.txt');
})();

export default async function () {
  // About information about the file
  const fileinfo = await file.stat();
  if (fileinfo.name != 'bonjour.txt') {
    throw new Error('Unexpected file name');
  }

  const buffer = new Uint8Array(128);

  let totalBytesRead = 0;
  while (true) {
    // Read into the buffer
    const bytesRead = await file.read(buffer);
    if (bytesRead == null) {
      // EOF
      break;
    }

    // Do something useful with the content of the buffer
    totalBytesRead += bytesRead;

    // If bytesRead is less than the buffer size, we've read the whole file
    if (bytesRead < buffer.byteLength) {
      break;
    }
  }

  // Check that we read the expected number of bytes
  if (totalBytesRead != fileinfo.size) {
    throw new Error('Unexpected number of bytes read');
  }

  // Seek back to the beginning of the file
  await file.seek(0, SeekMode.Start);
}

Redis (m)TLS support and new Client constructor options #3439, xk6-redis/#17

In this release, the k6/experimental/redis module receives several important updates, including breaking changes.

Connection URLs

The Client constructor now supports connection URLs to configure connections to Redis servers or clusters. These URLs can be in the format redis://[[username][:password]@][host][:port][/db-number] for standard connections, or rediss://[[username][]:password@]][host][:port][/db-number] for TLS-secured connections. For more details, refer to the documentation.

Example usage

import redis from 'k6/experimental/redis';

const redisClient = new redis.Client('redis://someusername:somepassword@localhost:6379/0');

Revamped Options object

The Client constructor has been updated with a new Options object format. This change aligns the module with familiar patterns from Node.js and Deno libraries, offering enhanced flexibility and control over Redis connections. For more details, refer to the documentation.

Expand to see an example of the new functionality.

This example shows the usage of the new Options object:

import redis from 'k6/experimental/redis';

const redisClient = new redis.Client({
  socket: {
    host: 'localhost',
    port: 6379,
  },
  username: 'someusername',
  password: 'somepassword',
});

(m)TLS support

The Redis module now includes (m)TLS support, enhancing security for connections. This update also improves support for Redis clusters and sentinel modes (failover). For connections using self-signed certificates, enable k6’s insecureSkipTLSVerify option (set to true).

Expand to see an example of the new functionality.

This example shows the configuration of a TLS connection:

import redis from 'k6/experimental/redis';

const redisClient = new redis.Client({
  socket: {
    host: 'localhost',
    port: 6379,
    tls: {
      ca: [open('ca.crt')],
      cert: open('client.crt'), // client certificate
      key: open('client.key'), // client private key
    },
  },
});

Add tracing instrumentation #3445

k6 now supports a new traces output option that allows you to configure the output for traces generated during its execution. This option can be set through the --traces-output argument in the k6 run command or by setting the K6_TRACES_OUTPUT environment variable.

Currently, no traces are generated by k6 itself, but this feature represents the first step towards richer tracing functionalities in k6 and its extensions.

By default traces output is set to none, and currently the only supported output is otel which uses the opentelemetry-go’s Open Telemetry API and SDK implementations. The format for the otel traces output configuration is the following:

--traces-output=<endpoint>[,opt1=val1,opt2=val2]

Where opts can be one of the following options:

proto: Specifies the protocol to use in the connection to the traces backend. Supports grpc (default) and http.
header.<header_name>: Specifies an additional header to include in the connection to the traces backend.

Example:

K6_TRACES_OUTPUT=https://traces.k6.io/v1/traces,proto=http,header.Authorization=Bearer token

Add support for browser module’s `page.throttleCPU` browser#1095

The browser module now supports throttling the CPU from chrome/chromium’s perspective by using the throttleCPU API, which helps emulate slower devices when testing the website’s frontend. It requires an argument of type CPUProfile, which includes a rate field that is a slow-down factor, where 1 means no throttling, 2 means 2x slowdown, and so on. For more details, refer to the documentation.

...
  const context = browser.newContext();
  const page = context.newPage();

  try {
    page.throttleCPU({ rate: 4 });
...

Add support for browser module’s `page.throttleNetwork` browser#1094

The browser module now supports throttling the characteristics of the network from chrome/chromium’s perspective by using the throttleNetwork API, which helps emulate slow network connections when testing the website’s frontend. It requires an argument of type NetworkProfile, with a definition of:

export interface NetworkProfile {
  /*
   * Minimum latency from request sent to response headers received (ms).
   */
  latency: number;

  /*
   * Maximal aggregated download throughput (bytes/sec). -1 disables download
   * throttling.
   */
  download: number;

  /*
   * Maximal aggregated upload throughput (bytes/sec). -1 disables upload
   * throttling.
   */
  upload: number;
}

You can either define your own network profiles or use the ones we have defined by importing networkProfiles from the browser module. For more details, refer to the documentation.

import { browser, networkProfiles } from 'k6/experimental/browser';
...
  const context = browser.newContext();
  const page = context.newPage();

  try {
    page.throttleNetwork(networkProfiles['Slow 3G']);
...

k6’s documentation is moving under grafana.com/docs/k6

It’s not directly part of the k6 v0.48 release, but we believe it is worth mentioning that we’re moving the documentation from k6.io/docs to grafana.com/docs/k6.

The legacy documentation space k6.io/docs will be available for a while, but we encourage you to update your bookmarks and links to the new domain.

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

Version 0.47.0 release notes

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

Version 0.47.0 release notes

k6 v0.47.0 is here 🎉! This release includes:

Deprecations

#3347 The built-in statsd output option has been deprecated, and users should use the xk6-output-statsd extension instead. See #2982 for future plans.
#3288 Loading remote modules now requires users to prepend them with https://. Before, k6 would try to resolve importing remote modules by prepending https:// if it was missing. This behavior has been deprecated and will be fully removed in the next release (v0.48.0).

New features

Add gRPC’s binary metadata support #3234, xk6-grpc#46

The k6 gRPC modules (k6/net/grpc and k6/experimental/grpc) now support handling binary metadata that uses the -bin postfix, according to the gRPC specification.

let resp = client.invoke(
  'grpc.testing.TestService/EmptyCall',
  {},
  { metadata: { 'X-Load-Tester-bin': new Uint8Array([2, 200]) } }
);

Thanks to @sapphire-janrain for the contribution!

Add gRPC’s reflection metadata support #3343, xk6-grpc#46

The k6 gRPC modules (k6/net/grpc and k6/experimental/grpc) now support adding metadata to reflection requests by using a new connection parameter reflectMetadata.

Higher precision for Trend metrics in Grafana Cloud k6 #3302

Grafana Cloud k6 is now able to store and visualize Trend metrics up to 3 digits of precision for decimal numbers.

Docker support for browser-based tests #3199

k6 is now publishig Docker images that include Chromium web browser. This allows k6 users to run tests that use Browser API without having to install Chrome first. Check the “A note on running browser tests” section of the Overview page on DockerHub for details.

Docker images for ARM64 architecture #3320

The k6’s release process now builds and pushes dedicated Docker images for ARM64. Check k6’s tags page on DockerHub for details.

New authentication methods and HTTP headers API for Prometheus remote write output xk6-output-prometheus-remote#143, xk6-output-prometheus-remote#145, xk6-output-prometheus-remote#147

The experimental Prometheus remote write output now supports two new authentication methods: Bearer token and TLS certificates. Check out the documentation to learn more about how to define them using the new environment variables. We’ve also added the K6_PROMETHEUS_RW_HTTP_HEADERS that defines a new and more convenient way to set custom HTTP headers to pass through each flush metrics’ request.

The browser module now provides a more complete and robust API for handling cookies. The cookie API was stabilized by defining a new Cookie class (browser#1008, browser#1030) that can be used while creating and retrieving cookies. This enabled us to add a new browserContext.cookies([urls]) method (browser#1005) that returns all cookies from the current browser context. The new API also supports filtering cookies by URL (browser#1016).

That led to fixing a bug where the expires field was not being set correctly while adding cookies using the context.addCookie() method (browser#1031). Lastly, the existing context.clearCookies() method was fixed to clear all cookies from the current browser context (browser#1040).

const context = browser.newContext();
context.addCookies([
  { name: 'foo', value: 'bar', url: 'https://test.k6.io' },
  { name: 'baz', value: 'qux', url: 'https://grafana.com' },
]);

const cookies = context.cookies('https://test.k6.io');
console.log(cookies.length); // 1
console.log(cookies[0].name); // foo
console.log(cookies[0].value); // bar

context.clearCookies();
console.log(context.cookies.length); // 0

Add support for browser module’s `page.on('console')` browser#1006

Allows users to register a handler to be executed every time the console API methods are called from within the page’s JavaScript context. The arguments passed into the handler are defined by the ConsoleMessage class.

page.on('console', (msg) => {
  check(msg, {
    assertConsoleMessageType: (msg) => msg.type() == 'log',
    assertConsoleMessageText: (msg) => msg.text() == 'this is a console.log message 42',
    assertConsoleMessageArgs0: (msg) =>
      msg.args()[0].jsonValue() == 'this is a console.log message',
    assertConsoleMessageArgs1: (msg) => msg.args()[1].jsonValue() == 42,
  });
});

page.evaluate(() => console.log('this is a console.log message', 42));

For a full list of changes, including UX improvements and bug fixes, refer to full release notes.

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

k6 v1.8.0 is here! This maintenance release on v1.x includes:

Cloud secrets are now automatically available in k6 cloud run --local-execution — use --no-cloud-secrets to opt out.
Pre-manifest extension dependencies are captured in archive metadata for cloud consumers.
Structured logging from k6provider for better visibility into automatic extension provisioning.
Multiple bug fixes for Browser, WebSocket, and Cloud modules.
Dependency updates and reliability improvements.

Breaking changes

There are no breaking changes in this release.

New features

Cloud secrets now automatically available in local execution #5738 & #5875

When running k6 cloud run --local-execution, secrets stored in Grafana Cloud are now automatically available to your script via secrets.get() without any additional configuration.

To opt out, pass --no-cloud-secrets:

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

Thanks, @vortegatorres!

Pre-manifest extension dependencies captured in archive metadata #5819 & #5977

When creating a k6 archive (k6 archive), extension dependency information is now captured in metadata.json under a "dependencies" field, using the constraints declared by the script before any external manifest overrides are applied. This ensures that k6/x/ imports are preserved correctly during auto-extension-resolution re-execution.

UX improvements and enhancements

#5815 & #5993 Warns when http.get() or http.head() receive extra arguments that are silently ignored, helping catch common scripting mistakes. Thanks, @moko-poi!
#5657 Adds automatic retries to newAction-based Locator APIs in the browser module, improving reliability of browser tests. Thanks, @janHildebrandt98!
#5845 Wires k6provider’s structured logging into k6’s logger. Provisioning operations (artifact resolution, cache hits, downloads, retries, and cache pruning) now appear in k6’s log output at the correct level.

Bug fixes

#5855 Fixes auto-extension-resolution incorrectly triggering binary provisioning when a script manifest specifies a dependency as a Go module pseudo-version (v0.0.0+sha or v0.0.0-timestamp-sha), even when the running binary already satisfied the constraint.
#5574 Fixes position parser for base pointer options. Thanks, @chrismooreproductions!
#5630 & #5987 Fixes duplicate redirect request metric emissions in the browser module, where each redirect was incorrectly emitting metrics for all prior redirects in the chain.
#5620 & #5991 Preserves context cancellation causes across the scheduler, browser, and secret-source layers, improving the accuracy of error messages surfaced when a test is interrupted. Thanks, @LBaronceli!
#5716 & #5990 Fixes WebSocket bufferedAmount not being incremented when sending TypedArrays, causing it to go negative. Thanks, @prakharbirla-ng!
#5814 & #5975 Fixes k6 cloud run --local-execution ignoring K6_CLOUD_PUSH_REF_ID and unconditionally creating a new test run instead of reusing the provided run ID. Thanks, @Reranko05!
#5786 Fixes swapped Min and Max values for Gauge metrics in Cloud output v2, which caused incorrect peak and floor values in cloud test result queries. Thanks, @esquonk!
#5785 Fixes a race condition in the browser module’s handleExitEvent where Done() was signalled before the subscription was removed, causing tests to hang until the timeout.
#5905 Fixes a deadlock where WebSocket connections hang forever during teardown when the server sends pings. A server ping arriving during shutdown could permanently stall the k6 process.
#5923 & #5989 Fixes a nil pointer panic in ElementHandle.DefaultTimeout (and any method that calls it, such as GetAttribute) when invoked on a nil or partially-initialized handle. Thanks, @SAY-5!

Maintenance and internal improvements

#5896 & #5897 Updates go.opentelemetry.io/otel/exporters/otlp/otlptracehttp and otlpmetrichttp to v1.43.0 [security], adding a 4 MiB response body cap to mitigate memory exhaustion from misconfigured or malicious servers.
#5857, #5950 Updates Go to v1.25.10.
#5946 Updates golang.org/x/net to v0.55.0 [security].
#6042 Updates Go toolchain to v1.25.11 [security].
#6047 Updates golang.org/x/crypto to v0.52.0 [security].
#5863, #5880, #5908 Updates github.com/grafana/k6provider to v0.5.0.
#5740, #5796, #5910 Updates github.com/grafana/sobek digest.
#6035 Move Docker Hub publishing to GAR mirror.
#6064 Bumps Dockerfile images for security updates.

External contributors

A huge thank you to the external contributors who helped during this release: @moko-poi, @janHildebrandt98, @Reranko05, @prakharbirla-ng, @esquonk, @chrismooreproductions, @vortegatorres, @SAY-5, and @LBaronceli! 🙏

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

k6 v1.8.1 is here! This patch release includes:

Bug fix for the cloud secret source being enabled by default, which broke scripts that configure their own secret source
Bug fix for HTTP/2 negotiation and error classification under Go 1.27
Security updates for gRPC, golang.org/x/net, golang.org/x/text, golang.org/x/crypto, OpenTelemetry, klauspost/compress, and the Go toolchain

Bug fixes

#6274 Stops enabling the Grafana Cloud secret source by default in k6 cloud run --local-execution, reverting #5875. Scripts that configured their own secret source failed with no secret source with name "default" is configured. Explicitly configured secret sources now work again as they did in v1.7. Fixes #6093.
#6275 Fixes HTTP/2 negotiation and error classification under Go 1.27, which changed HTTP/2 negotiation and error behaviour. Keeps VUs on HTTP/2, classifies connection and GOAWAY errors consistently across Go versions, and preserves unknown HTTP/2 error buckets. Backport of #6234.

Maintenance and security updates

#6193, #6194 Updates google.golang.org/grpc to v1.82.1 [security].
#6187, #6189 Updates golang.org/x/net to v0.56.0 [security].
#6188, #6190 Updates golang.org/x/text to v0.39.0 [security].
#6207 Updates go.opentelemetry.io/otel to v1.44.0 [security].
#6220 Updates github.com/klauspost/compress to v1.18.7 [security].
#6135 Updates the Go toolchain to v1.25.12 [security].
Updates golang.org/x/crypto to v0.53.0 [security].

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

k6 v2.0.0-rc1 is here 🎉!

This release marks the first release candidate for k6 v2.0.0 — a major version that completes a long-running cleanup of deprecated APIs, old commands, and obsolete configuration options. Like the v1.0.0-rc1 before it, the purpose of this release is to give the community a chance to test the upgrade path, identify any issues, and migrate scripts or workflows affected by breaking changes. If you encounter any problems, please report them.

Here’s a glimpse of what’s changed in this release:

The Go module path has changed to go.k6.io/k6/v2 — all extensions must update their import paths to be compatible with v2.
Removal of all long-deprecated CLI commands and flags: k6 login, k6 pause, k6 resume, k6 scale, k6 status, --no-summary, --upload-only, and more.
The externally-controlled executor has been removed — scripts using executor: externally-controlled will no longer run.
Cloud run non-threshold aborts (aborted by user, system, timeout, etc.) now return exit code 97 instead of 0.
options.ext.loadimpact is no longer supported — use options.cloud.
k6/experimental/redis module has been removed.
The k6 cloud command now shows help by default instead of attempting to run.
A stack is now required for all k6 cloud commands — the previous fallback to the first available stack has been removed.
The web-vitals library has been updated to v5.1.0, removing the deprecated FID metric.

Breaking changes

These are changes that require you to update your scripts, CI/CD pipelines, or configuration files before upgrading.

Go module path changed to `go.k6.io/k6/v2` #5777

Following the Go module versioning conventions, the k6 module path has changed from go.k6.io/k6 to go.k6.io/k6/v2.

Any extension or external package that imports go.k6.io/k6 must update all import paths to go.k6.io/k6/v2. For the vast majority of extensions this is the only change needed — a mechanical find-and-replace across the codebase:

go.k6.io/k6/ → go.k6.io/k6/v2/

For example:

// Before
import "go.k6.io/k6/js/modules"

// After
import "go.k6.io/k6/v2/js/modules"

As a result, no existing extensions will be compatible with v2.0.0-rc1. As we move toward the final v2.0.0 release, we expect most extensions to either already support the new path or to do so shortly after.

Removed CLI commands #5653

The following commands for controlling a running test have been removed. They have not been functional for most use cases since the REST API they relied on was limited to specific execution modes:

k6 pause
k6 resume
k6 scale
k6 status

Migration: There is no replacement. These commands relied on the externally-controlled executor, which has also been removed in v2.0.0 (see below).

Removed `externally-controlled` executor #5846

The externally-controlled executor has been removed. It was legacy code from an older k6 Cloud architecture that allowed external systems to scale VUs and pause/resume a running test via the k6 REST API — the capability that k6 pause, k6 resume, k6 scale, and k6 status relied on.

Migration: There is no replacement. Any test script with executor: externally-controlled will fail to start. Migrate to a different executor based on the desired load profile (e.g., ramping-vus, constant-vus, constant-arrival-rate).

Removed `k6 login` command #5134

The top-level k6 login command and its subcommands (k6 login cloud, k6 login influxdb) have been removed.

Migration:

Replace k6 login cloud → k6 cloud login
InfluxDB authentication is no longer configurable via a login command. Use environment variables such as K6_INFLUXDB_* to configure the InfluxDB output directly.

`k6 cloud script.js` no longer runs a test #5624

Running k6 cloud without an explicit subcommand (i.e., the old positional-argument form k6 cloud script.js) now shows the help output instead of attempting to run the test. The run subcommand was already the recommended path since k6 cloud run was introduced.

Migration: Replace k6 cloud script.js with k6 cloud run script.js.

Removed `--upload-only` flag #5844

The --upload-only flag on the k6 cloud command has been removed.

Migration: Use k6 cloud upload script.js to upload a test without running it.

Removed `--no-summary` flag #5729

The --no-summary flag has been removed.

Migration: Replace --no-summary with --summary-mode=disabled.

Removed `--summary-mode=legacy` #5730

The legacy value for --summary-mode has been removed.

Migration: There is no direct equivalent — the new summary format is different from the legacy one. Review the available summary modes and choose the one that best fits your needs: compact (the default) or full for more detailed output.

Removed `options.ext.loadimpact` support #5774

The options.ext.loadimpact configuration block in test scripts is no longer supported.

Migration: Move all cloud-related configuration from options.ext.loadimpact to options.cloud:

// Before
export const options = {
  ext: {
    loadimpact: {
      projectID: 12345,
      name: "My Test",
    },
  },
};
export default () => {}

// After
export const options = {
  cloud: {
    projectID: 12345,
    name: "My Test",
  },
};
export default () => {}

Removed `k6/experimental/redis` module #5485

The k6/experimental/redis module has been removed from the k6 core binary. It was shipped as an experiment and has not been promoted to stable.

Migration: Change your import from k6/experimental/redis to k6/x/redis. With auto-extension-resolution, k6 will automatically provision the xk6-redis extension when it sees the k6/x/redis import.

Removed `ExporterType` option from OpenTelemetry output #5754

The deprecated exporterType configuration option for the OpenTelemetry output has been removed.

Migration: Replace K6_OTEL_EXPORTER_TYPE with K6_OTEL_EXPORTER_PROTOCOL. The accepted values are grpc and http/protobuf.

Removed `SingleCounterForRate` option from OpenTelemetry output #5830

The temporary SingleCounterForRate escape-hatch option for the OpenTelemetry output has been removed. It was introduced as a one-release migration aid in #5164 to let users revert to the old pair-of-counters format (<metric>.occurred + <metric>.total) while upgrading. Rate metrics are now always exported as a single counter with a condition attribute (nonzero/zero).

Migration: Remove any K6_OTEL_SINGLE_COUNTER_FOR_RATE=true configuration. If you were using the old pair-of-counters format, update your dashboards and queries to use the single counter with condition attribute instead.

Removed `K6_BINARY_PROVISIONING` environment variable #5734

The K6_BINARY_PROVISIONING environment variable, deprecated in v1.2.0, has been removed.

Migration: Remove K6_BINARY_PROVISIONING from your environment. Auto-extension-resolution is enabled by default; K6_AUTO_EXTENSION_RESOLUTION only needs to be set explicitly if you want to disable it.

Removed `K6_ENABLE_COMMUNITY_EXTENSIONS` environment variable #5733

The K6_ENABLE_COMMUNITY_EXTENSIONS environment variable has been removed. The community and cloud extension catalogs were merged server-side, making this flag a no-op since the catalogs were unified.

Migration: Remove K6_ENABLE_COMMUNITY_EXTENSIONS from your environment. Community extensions are now resolved through the default build service URL automatically.

Stack is now required for all `k6 cloud` commands #5833

Providing a stack is now mandatory for all k6 cloud commands (k6 cloud run, k6 cloud upload, k6 cloud run --local-execution). Previously, omitting a stack would fall back to the first available stack with a deprecation warning — that fallback has been removed. Likewise, k6 cloud login now requires both a token and a stack; passing one without the other fails with an explicit error.

Migration: Ensure a stack is always provided via k6 cloud login --stack passing the stack slug or the full URL. Alternatively, the K6_CLOUD_STACK_ID environment variable, or the stackID script option are available to be set before running any k6 cloud command .

Removed legacy configuration file path migration #5609

k6 no longer automatically migrates configuration files from the old {USER_CONFIG_DIR}/loadimpact/config.json path introduced before k6 v1.0.0.

Migration: If you still have a config file at the old path, move it to {USER_CONFIG_DIR}/k6/config.json. You can also re-run k6 cloud login to regenerate the file at the correct location.

Cloud run non-threshold aborts now exit with code 97 #5769

Previously, most cloud abort scenarios returned an exit code of 0, making it impossible for CI pipelines to distinguish a failed run from a successful one. These scenarios now return exit code 97.

Scenario	Before	After
Finished	`0`	`0`
Aborted by threshold	`99`	`99`
Aborted by system, limit, script error, user, or timeout	`0`	`97`

Migration: Review any CI pipeline logic that treats exit code 0 as success for cloud runs. Cloud runs that abort for reasons other than threshold violations will now return exit code 97.

Browser: FID metric removed, web vitals updated to v5.1.0 #5661

The browser_web_vital_fid metric has been removed. FID (First Input Delay) was deprecated as a Core Web Vital and replaced by INP (Interaction to Next Paint). The embedded web-vitals library has been updated from v3 to v5.1.0, which reflects this change.

Migration: Update any dashboards, alerts, or threshold rules that reference browser_web_vital_fid to use browser_web_vital_inp instead.

New features

Cloud secret source #5738

A new built-in secret source, cloud, allows k6 scripts to retrieve secrets stored in Grafana Cloud directly during local execution. Pass --secret-source=cloud when running k6 cloud run --local-execution to make cloud-managed secrets available to your script via secrets.get(). Thanks, @vortegatorres!

k6 cloud run --local-execution --secret-source=cloud script.js

Extension tab-completion provisioning #5761

When using shell tab-completion, pressing TAB after a fully-typed extension name (e.g. k6 x docs <TAB>) will now automatically provision a custom binary with that extension and delegate the completion request to it. This means extension-specific flags and subcommands are available via tab-completion without any manual setup.

Pre-manifest extension dependencies captured in archive metadata #5819

UX improvements and enhancements

#5815 Warns when http.get() or http.head() receive extra arguments that are silently ignored, helping catch common scripting mistakes. Thanks, @moko-poi!
#5657 Adds automatic retries to newAction-based Locator APIs in the browser module, improving reliability of browser tests. Thanks, @janHildebrandt98!
#5779 Adds a k6 x docs hint to the main k6 help output for built-in documentation discovery. Thanks, @Reranko05!
#5788 Adds a k6 x explore hint to the main k6 help output for extension discovery.

Bug fixes

#5855 Fixes auto-extension-resolution incorrectly triggering binary provisioning when a script manifest specifies a dependency as a Go module pseudo-version (v0.0.0+sha or v0.0.0-timestamp-sha), even when the running binary already satisfied the constraint.
#5769 Fixes several k6 cloud run TUI issues: ghost duplicate progress bars appearing after the run finishes, a timer that stalled and then jumped to 100%, and a stale timer racing with the status line.
#5814 Fixes k6 cloud run --local-execution ignoring K6_CLOUD_PUSH_REF_ID and unconditionally creating a new test run instead of reusing the provided run ID. Thanks, @Reranko05!
#5716 Fixes WebSocket bufferedAmount not being incremented when sending TypedArrays, causing it to go negative. Thanks, @prakharbirla-ng!
#5630 Fixes duplicate redirect request metric emissions in the browser module, where each redirect was incorrectly emitting metrics for all prior redirects in the chain.
#5786 Fixes swapped Min and Max values for Gauge metrics in Cloud output v2, which caused incorrect peak and floor values in cloud test result queries. Thanks, @esquonk!
#5785 Fixes a race condition in the browser module’s handleExitEvent where Done() was signalled before the subscription was removed, causing tests to hang until the timeout.
#5574 Fixes position parser for base pointer options. Thanks, @chrismooreproductions!

Maintenance and internal improvements

#5847 Moves TaskQueue from the external github.com/mstoykov/k6-taskqueue-lib into internal/js/taskqueue, eliminating an awkward reverse dependency where the library’s own tests depended on k6.
#5775 Moves xk6-dashboard source code into internal/dashboard, making the web dashboard a built-in part of the k6 binary without requiring a separate extension. The dashboard is available via k6 run --out=web-dashboard.
#5703, #5818 Uses Go’s synctest package within lib/executor, eventloop, and timer tests for virtualized time, improving test determinism.
#5778 Bumps Ubuntu CI runners to 24.04 and always installs Chromium for browser tests.
#5826, #5827 Updates go.opentelemetry.io/otel/exporters/otlp/otlptracehttp and otlpmetrichttp to v1.43.0 [security], adding a 4 MiB response body cap to mitigate memory exhaustion from misconfigured or malicious servers.
#5669 Updates go.opentelemetry.io/otel packages.
#5740, #5796 Updates github.com/grafana/sobek digest.
#5783, #5838, #5862 Updates github.com/grafana/k6-cloud-openapi-client-go.
#5407, #5801 Updates github.com/mailru/easyjson to v0.9.2.
#5616, #5805 Updates github.com/evanw/esbuild to v0.28.0.
#5667 Updates golangci-lint.
#5799 Updates buf.build/gen/go/prometheus protobuf.
#5800 Updates github.com/andybalholm/brotli to v1.2.1.
#5804 Updates examples/ dependencies.
#5806 Updates github.com/fatih/color to v1.19.0.
#5807 Updates github.com/puerkitobio/goquery to v1.12.0.
#5840 Updates github.com/mattn/go-isatty to v0.0.21.
#5857 Updates Go to v1.25.9.
#5863, #5880 Updates github.com/grafana/k6provider to v0.4.0.
#5670 Updates GitHub artifact actions (major).
#5693 Updates crazy-max/ghaction-chocolatey to v4.
#5706 Updates actions/setup-go to 4a36011.
#5707 Updates anchore/sbom-action to v0.24.0.
#5718, #5861 Updates github/codeql-action to v4.35.2.
#5720, #5802 Updates docker/login-action to v4.1.0.
#5771, #5798 Updates grafana/shared-workflows actions.
#5836 Updates actions/upload-artifact.
#5809, #5839 Updates the Docker base image tags (Debian to v13, Go to v1.26.2).
#5872 Fixes v6 cloud client losing the request body when retrying after a Connection: close response.
#5871 Returns an accurate error from the v6 cloud client when a test name lookup returns no results.
#5751 Updates github.com/klauspost/compress to v1.18.5.
#5841 Updates golang.org/x packages.
#5860 Updates Alpine Docker image to v3.23.4.

External contributors

A huge thank you to the external contributors who helped during this release: @moko-poi, @janHildebrandt98, @Reranko05, @prakharbirla-ng, and @chrismooreproductions! 🙏

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

k6 v2.0.0 is here 🎉!

k6 v2.0.0 is the final release of the v2 major version, completing the cleanup of deprecated APIs, old commands, and obsolete configuration options that was started with v2.0.0-rc1. If you were already running the release candidate, this release includes a handful of additional changes on top — they are marked with (new since v2.0.0-rc1) throughout these notes.

Here’s a glimpse of what’s changed in this release:

The Go module path has changed to go.k6.io/k6/v2 — all extensions must update their import paths to be compatible with v2.
Removal of all long-deprecated CLI commands and flags: k6 login, k6 pause, k6 resume, k6 scale, k6 status, --no-summary, --upload-only, and more.
The externally-controlled executor has been removed — scripts using executor: externally-controlled will no longer run.
Cloud run non-threshold aborts (aborted by user, system, timeout, etc.) now return exit code 97 instead of 0.
options.ext.loadimpact is no longer supported — use options.cloud.
k6/experimental/redis module has been removed.
The k6 cloud script.js positional form has been fully removed — use k6 cloud run script.js.
A stack is now required for all k6 cloud commands — the previous fallback to the first available stack has been removed.
The web-vitals library has been updated to v5.1.0, removing the deprecated FID metric.
(new since v2.0.0-rc1) easyjson has been dropped in favor of stdlib encoding/json — extension authors relying on easyjson-generated methods on k6 types must update.
(new since v2.0.0-rc1) The k6 HTTP API server no longer starts by default — pass --address to enable it.
(new since v2.0.0-rc1) New k6 cloud project list command to list Grafana Cloud k6 projects.
(new since v2.0.0-rc1) Cloud secrets are now automatically available in k6 cloud run --local-execution; use --no-cloud-secrets to opt out.

Breaking changes

These are changes that require you to update your scripts, CI/CD pipelines, or configuration files before upgrading.

Go module path changed to `go.k6.io/k6/v2` #5777

Following the Go module versioning conventions, the k6 module path has changed from go.k6.io/k6 to go.k6.io/k6/v2.

go.k6.io/k6/ → go.k6.io/k6/v2/

For example:

// Before
import "go.k6.io/k6/js/modules"

// After
import "go.k6.io/k6/v2/js/modules"

Removed CLI commands #5653

The following commands for controlling a running test have been removed. They have not been functional for most use cases since the REST API they relied on was limited to specific execution modes:

k6 pause
k6 resume
k6 scale
k6 status

Migration: There is no replacement. These commands relied on the externally-controlled executor, which has also been removed in v2.0.0 (see below).

Removed `externally-controlled` executor #5846

Removed `k6 login` command #5134

The top-level k6 login command and its subcommands (k6 login cloud, k6 login influxdb) have been removed.

Migration:

Replace k6 login cloud → k6 cloud login
InfluxDB authentication is no longer configurable via a login command. Use environment variables such as K6_INFLUXDB_* to configure the InfluxDB output directly.

Removed `k6 cloud script.js` positional form #5624, #5912 (completed in v2.0.0)

The old positional-argument form k6 cloud script.js has been fully removed. In v2.0.0-rc1 it was changed to show help instead of running; in v2.0.0 the deprecated command handler itself has been removed entirely. The run subcommand has been the recommended path since k6 cloud run was introduced.

Migration: Replace k6 cloud script.js with k6 cloud run script.js.

Removed `--upload-only` flag #5844

The --upload-only flag on the k6 cloud command has been removed.

Migration: Use k6 cloud upload script.js to upload a test without running it.

Removed `--no-summary` flag #5729

The --no-summary flag has been removed.

Migration: Replace --no-summary with --summary-mode=disabled.

Removed `--summary-mode=legacy` #5730

The legacy value for --summary-mode has been removed.

Removed `options.ext.loadimpact` support #5774

The options.ext.loadimpact configuration block in test scripts is no longer supported.

Migration: Move all cloud-related configuration from options.ext.loadimpact to options.cloud:

// Before
export const options = {
  ext: {
    loadimpact: {
      projectID: 12345,
      name: "My Test",
    },
  },
};
export default () => {}

// After
export const options = {
  cloud: {
    projectID: 12345,
    name: "My Test",
  },
};
export default () => {}

Removed `k6/experimental/redis` module #5485

The k6/experimental/redis module has been removed from the k6 core binary. It was shipped as an experiment and has not been promoted to stable.

Removed `ExporterType` option from OpenTelemetry output #5754

The deprecated exporterType configuration option for the OpenTelemetry output has been removed.

Migration: Replace K6_OTEL_EXPORTER_TYPE with K6_OTEL_EXPORTER_PROTOCOL. The accepted values are grpc and http/protobuf.

Removed `SingleCounterForRate` option from OpenTelemetry output #5830

Removed `K6_BINARY_PROVISIONING` environment variable #5734

The K6_BINARY_PROVISIONING environment variable, deprecated in v1.2.0, has been removed.

Removed `K6_ENABLE_COMMUNITY_EXTENSIONS` environment variable #5733

Migration: Remove K6_ENABLE_COMMUNITY_EXTENSIONS from your environment. Community extensions are now resolved through the default build service URL automatically.

Stack is now required for all `k6 cloud` commands #5833

Migration: Run k6 cloud login which will ask you for the stack and setup correctly for the new version of k6. Alternatively, the K6_CLOUD_STACK_ID environment variable, or the stackID script option are available to be set before running any k6 cloud command .

Removed legacy configuration file path migration #5609

k6 no longer automatically migrates configuration files from the old {USER_CONFIG_DIR}/loadimpact/config.json path introduced before k6 v1.0.0.

Migration: If you still have a config file at the old path, move it to {USER_CONFIG_DIR}/k6/config.json. You can also re-run k6 cloud login to regenerate the file at the correct location.

Cloud run non-threshold aborts now exit with code 97 #5769

Scenario	Before	After
Finished	`0`	`0`
Aborted by threshold	`99`	`99`
Aborted by system, limit, script error, user, or timeout	`0`	`97`

Migration: Review any CI pipeline logic that treats exit code 0 as success for cloud runs. Cloud runs that abort for reasons other than threshold violations will now return exit code 97.

Browser: FID metric removed, web vitals updated to v5.1.0 #5661

Migration: Update any dashboards, alerts, or threshold rules that reference browser_web_vital_fid to use browser_web_vital_inp instead.

Dropped easyjson in favor of stdlib encoding/json (new since v2.0.0-rc1) #5853

k6 no longer uses easyjson for JSON serialization. Several types in the public Go API previously had easyjson-generated MarshalJSON/UnmarshalJSON methods; those are now gone, replaced by stdlib encoding/json. This change was intentionally held until v2 to avoid a breaking change mid-cycle.

Migration: Extension authors who relied on easyjson-generated methods on k6 types should remove those dependencies. Standard encoding/json marshaling applies to all affected types.

HTTP API server no longer starts by default (new since v2.0.0-rc1) #5876

The k6 HTTP API server no longer starts automatically. Previously, k6 always listened on localhost:6565 unless opted out. The server now only starts when an address is explicitly provided via the --address flag or the K6_ADDRESS environment variable.

Migration: If you use the k6 REST API, pass --address=localhost:6565 (or any address) to re-enable the server.

New features

Cloud secret source #5738

k6 cloud run --local-execution --secret-source=cloud script.js

Cloud secret source enabled by default for local execution (new since v2.0.0-rc1) #5875

--secret-source=cloud is no longer required. When running k6 cloud run --local-execution, the cloud secret source is now automatically available and secrets.get() works out of the box.

To opt out, pass --no-cloud-secrets:

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

`k6 cloud project list` command (new since v2.0.0-rc1) #5650

A new k6 cloud project command group has been added, with a k6 cloud project list subcommand for listing Grafana Cloud k6 projects. The output supports both human-readable table format and JSON (--format=json).

k6 cloud project list
k6 cloud project list --format=json

Extension tab-completion provisioning #5761

Pre-manifest extension dependencies captured in archive metadata #5819

UX improvements and enhancements

#5815 Warns when http.get() or http.head() receive extra arguments that are silently ignored, helping catch common scripting mistakes. Thanks, @moko-poi!
#5657 Adds automatic retries to newAction-based Locator APIs in the browser module, improving reliability of browser tests. Thanks, @janHildebrandt98!
#5779 Adds a k6 x docs hint to the main k6 help output for built-in documentation discovery. Thanks, @Reranko05!
#5788 Adds a k6 x explore hint to the main k6 help output for extension discovery.
(new since v2.0.0-rc1) #5869 Improves cloud authentication error messages — instead of a single generic error, k6 now reports specifically whether a token or a stack ID is missing.
(new since v2.0.0-rc1) #5845 Wires k6provider’s structured logging into k6’s logger. Provisioning operations (artifact resolution, cache hits, downloads, retries, and cache pruning) now appear in k6’s log output at the correct level.
(new since v2.0.0-rc1) Exposes the host k6 version to provisioned subcommands via K6_PROVISION_HOST_VERSION, so extension subcommands can correctly identify the caller’s k6 version when showing docs or feature information.
(new since v2.0.0-rc1) Tab completion no longer blocks on a build when the requested extension binary is not in the local cache — completions bail out instantly on a cache miss instead of waiting 10–30 seconds.

Bug fixes

#5855 Fixes auto-extension-resolution incorrectly triggering binary provisioning when a script manifest specifies a dependency as a Go module pseudo-version (v0.0.0+sha or v0.0.0-timestamp-sha), even when the running binary already satisfied the constraint.
#5769 Fixes several k6 cloud run TUI issues: ghost duplicate progress bars appearing after the run finishes, a timer that stalled and then jumped to 100%, and a stale timer racing with the status line.
#5814 Fixes k6 cloud run --local-execution ignoring K6_CLOUD_PUSH_REF_ID and unconditionally creating a new test run instead of reusing the provided run ID. Thanks, @Reranko05!
#5716 Fixes WebSocket bufferedAmount not being incremented when sending TypedArrays, causing it to go negative. Thanks, @prakharbirla-ng!
#5630 Fixes duplicate redirect request metric emissions in the browser module, where each redirect was incorrectly emitting metrics for all prior redirects in the chain.
#5786 Fixes swapped Min and Max values for Gauge metrics in Cloud output v2, which caused incorrect peak and floor values in cloud test result queries. Thanks, @esquonk!
#5785 Fixes a race condition in the browser module’s handleExitEvent where Done() was signalled before the subscription was removed, causing tests to hang until the timeout.
#5574 Fixes position parser for base pointer options. Thanks, @chrismooreproductions!
(new since v2.0.0-rc1) #5905 Fixes a deadlock where WebSocket connections hang forever during teardown when the server sends pings. A server ping arriving during shutdown could permanently stall the k6 process.
(new since v2.0.0-rc1) #5923 Fixes a nil pointer panic in ElementHandle.DefaultTimeout (and any method that calls it, such as GetAttribute) when invoked on a nil or partially-initialized handle. Thanks, @SAY-5!
(new since v2.0.0-rc1) #5620 Preserves context cancellation causes across the scheduler, browser, and secret-source layers, improving the accuracy of error messages surfaced when a test is interrupted. Thanks, @LBaronceli!

Maintenance and internal improvements

#5847 Moves TaskQueue from the external github.com/mstoykov/k6-taskqueue-lib into internal/js/taskqueue, eliminating an awkward reverse dependency where the library’s own tests depended on k6.
#5775 Moves xk6-dashboard source code into internal/dashboard, making the web dashboard a built-in part of the k6 binary without requiring a separate extension. The dashboard is available via k6 run --out=web-dashboard.
#5703, #5818, #5817 Uses Go’s synctest package within lib/executor, eventloop, timer, PeriodicFlusher, output/cloud, and output/cloud/expv2 tests for virtualized time, improving test determinism and CI speed.
#5778 Bumps Ubuntu CI runners to 24.04 and always installs Chromium for browser tests.
#5826, #5827 Updates go.opentelemetry.io/otel/exporters/otlp/otlptracehttp and otlpmetrichttp to v1.43.0 [security], adding a 4 MiB response body cap to mitigate memory exhaustion from misconfigured or malicious servers.
#5669, #5911 Updates go.opentelemetry.io/otel packages.
#5740, #5796, #5910 Updates github.com/grafana/sobek digest.
#5783, #5838, #5862 Updates github.com/grafana/k6-cloud-openapi-client-go.
#5616, #5805 Updates github.com/evanw/esbuild to v0.28.0.
#5667 Updates golangci-lint.
#5799 Updates buf.build/gen/go/prometheus protobuf.
#5800 Updates github.com/andybalholm/brotli to v1.2.1.
#5804 Updates examples/ dependencies.
#5806 Updates github.com/fatih/color to v1.19.0.
#5807 Updates github.com/puerkitobio/goquery to v1.12.0.
#5840, #5931 Updates github.com/mattn/go-isatty to v0.0.22.
#5857, #5950 Updates Go to v1.25.10.
#5863, #5880, #5908 Updates github.com/grafana/k6provider to v0.5.0.
#5670 Updates GitHub artifact actions (major).
#5693 Updates crazy-max/ghaction-chocolatey to v4.
#5706 Updates actions/setup-go to 4a36011.
#5707 Updates anchore/sbom-action to v0.24.0.
#5718, #5861 Updates github/codeql-action to v4.35.2.
#5720, #5802 Updates docker/login-action to v4.1.0.
#5771, #5798 Updates grafana/shared-workflows actions.
#5836 Updates actions/upload-artifact.
#5809, #5839, #5951 Updates the Docker base image tags (Debian to v13, Go to v1.26.3).
#5872 Fixes v6 cloud client losing the request body when retrying after a Connection: close response.
#5871 Returns an accurate error from the v6 cloud client when a test name lookup returns no results.
#5751 Updates github.com/klauspost/compress to v1.18.5.
#5841 Updates golang.org/x packages.
#5860 Updates Alpine Docker image to v3.23.4.
(new since v2.0.0-rc1) #5864 Configures the v1 release branch to receive security updates via Renovate.
(new since v2.0.0-rc1) #5891 Sets K6ModPath to the v2 module path in the k6provider config so that k6 v2 correctly signals to k6build which module to resolve against (go.k6.io/k6/v2).
(new since v2.0.0-rc1) #5947 Reworks the release workflow so pre-releases and older-major maintenance releases no longer claim Docker :latest or the GitHub “Latest release” marker. Adds a floating :vN Docker tag (e.g. grafana/k6:v1) for users who want to pin to a major line.
(new since v2.0.0-rc1) #5945 Updates golang.org/x/net to v0.53.0 [security] (CVE-2026-33814).
(new since v2.0.0-rc1) #5932 Updates github.com/Masterminds/semver/v3 to v3.5.0.
(new since v2.0.0-rc1) #5966 Bumps github.com/Azure/go-ntlmssp to v0.1.1.
(new since v2.0.0-rc1) #5965 Bumps the Go version used by the xk6 test workflows to appease security scanners.

External contributors

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

k6 v2.1.0 is here 🎉! This release includes:

An opt-in feature-flag system — --features, the K6_FEATURES environment variable, and a k6 features discovery command — shipping with experimental native histograms for trend metrics as its first flag.
A context-level proxy option for browser contexts.
Subcommand discovery in k6 x, so binaries can report which extension commands they expose.

Breaking changes

There are no breaking changes in this release.

New features

`k6 cloud test list` command #6007

A new k6 cloud test command group has been added, with a k6 cloud test list subcommand that lists the load tests of a Grafana Cloud k6 project. It complements the k6 cloud project list command introduced in v2.0.0.

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.

Output defaults to a human-readable table. Pass --json to emit a JSON array instead, mirroring the format established by k6 cloud project list.

k6 cloud test list
k6 cloud test list --project-id 12345
k6 cloud test list --json

Feature flags and experimental native histograms #6055, #6056

k6 now has an opt-in feature-flag mechanism for trialing new, not-yet-stable behavior without affecting existing runs. Flags can be enabled on k6 run and k6 cloud run through the --features flag (comma-separated or repeated), the K6_FEATURES environment variable, or the features key in config.json. Enabled flags are surfaced as metric tags and propagated into archives and cloud workers so a run behaves consistently wherever it executes.

Use k6 features (or k6 features --json) to discover the available flags and their lifecycle:

$ k6 features
FEATURE             LIFECYCLE      DESCRIPTION
native-histograms   Experimental   Use native histograms for trend metrics

The first flag shipped is native-histograms, an experimental flag that makes k6 use native histograms for trend metrics:

k6 run --features native-histograms script.js
# or
K6_FEATURES=native-histograms k6 run script.js

Subcommand discovery in `k6 x` #5972

Running k6 x now lists the available subcommands — both the ones baked into the binary and those advertised by the extension registry (official and community). Tab-completion surfaces the same set once the catalog has been cached locally by a prior k6 x run, so completion never blocks on the network.

$ k6 x
...
Available Commands:
  agent       Bootstrap an AI-assisted k6 testing workflow in any editor
  docs        CLI k6 docs for AI agents and users
  explore     Explore k6 extensions for Automatic Resolution
  mcp         An MCP server for k6 for AI agents

This makes a k6 binary self-describing — particularly useful for AI agents driving k6, which previously had no way to introspect which extension subcommands were available.

Browser context proxy option #5924

Browser contexts can now be configured with a context-level proxy option, letting you route a context’s traffic through a proxy without launching a custom-built binary or relying on environment proxy variables (which only affected k6’s DevTools WebSocket connection). The option is wired to Chromium through Target.createBrowserContext, and invalid proxy configuration now fails early when proxy.server is missing. Thanks, @nightt5879!

const context = await browser.newContext({
  proxy: {
    server: "http://proxy.test:8080",
    bypass: "localhost,127.0.0.1",
  },
});

Browser `locator.isInViewport()` #6023

A new locator.isInViewport() method reports whether an element intersects the browser viewport. It accepts an optional ratio (0 to 1) that sets how much of the element must be visible, defaulting to 0 so any visible pixel counts, matching Playwright’s toBeInViewport semantics. The call waits for the element to attach, honoring the timeout option, then measures the intersection once. Thanks, @Anuragp22!

const button = page.locator("button#submit");
if (await button.isInViewport()) {
  await button.click();
}

Basic auth for the OpenTelemetry HTTP exporter #5997

The OpenTelemetry output’s HTTP exporter can now send HTTP Basic Auth credentials. Set them through the K6_OTEL_HTTP_EXPORTER_USERNAME and K6_OTEL_HTTP_EXPORTER_PASSWORD environment variables, or the username and password keys in the output config.

K6_OTEL_HTTP_EXPORTER_USERNAME=user \
K6_OTEL_HTTP_EXPORTER_PASSWORD=secret \
k6 run --out opentelemetry script.js

`single()` selection helper in `k6/html` #6002

Selection.single(selector) returns at most one matching element, backed by goquery’s Single matcher for a faster lookup than find() when you only need the first match. Thanks, @rohan-patnaik!

import { parseHTML } from "k6/html";

const doc = parseHTML(content);
const title = doc.single("h1").text();

UX improvements and enhancements

#5971 Tags browser API failures with module=browser so that browser errors surfaced in Grafana Cloud Logs can be filtered separately from other log sources.

Bug fixes

#5794 Makes the --vus flag work as a standalone execution shortcut instead of being silently ignored when a script defines scenarios. Running k6 run script.js --vus N now creates a shared-iterations scenario with N VUs and N iterations, overriding any script-defined scenarios with a warning — consistent with how --iterations, --duration, and --stages already behave. Thanks, @Reranko05!
#6013 Rejects invalid threshold percentiles. A percentile aggregation value outside the 0 to 100 range (or NaN) now fails parsing with a clear message instead of being silently accepted. Thanks, @immanuwell!
#6011 Writes the on-disk k6 config file with owner-only permissions (0o600, inside a 0o700 directory). The file can hold the Grafana Cloud API token (collectors.cloud.token), so tightening it keeps other local users on shared hosts (CI runners, multi-user boxes, sidecar containers) from reading the token. Existing configs are upgraded on the next write, for example the next k6 cloud login.

Maintenance and internal improvements

#6033 Moves Docker Hub image publishing to a Google Artifact Registry mirror.
#5953 Installs s3cmd via apt instead of pip to fix the k6packager image build.
#6052 Fixes the browser end-to-end test workflow.
#5984 Routes per-test logger output to the test instance instead of the global logrus, improving test isolation.
#5985 Fixes the flaky TestPageScreenshotFullpage browser test.
#5981 Lets Renovate track the Go minor version in the setup-go workflows.
#5968 Honors the caller-pinned ref in the shared lint action.
#6041, #6054 Aligns the Go module directive and toolchain (1.25.0 / 1.25.11).
#5967 Updates the release notes template after v2.0.0.
#6015 Updates golang.org/x/net to v0.55.0 [security].
#6026 Updates golang.org/x/crypto to v0.52.0 [security].
#5962, #6028 Updates google.golang.org/grpc to v1.81.1.
#5960 Updates grafana/shared-workflows/get-vault-secrets to v1.3.2.
#5958 Updates grafana/shared-workflows/azure-trusted-signing to v1.0.2.
#5957 Updates github/codeql-action to v4.35.4.
#5959 Updates grafana/shared-workflows/dockerhub-login to v1.0.4.
#6009 Moves the browser PageScreenshotOptions parsing into the mapping layer.
#5964 Adds the k6 feature-flags specification under openspec/.
#6067 Forces the legacy x/net/http2 implementation on the gotip CI test job.
#6065 Lets Renovate update the Dockerfile on the v1.x branch.
#6031 Updates go.opentelemetry.io/otel to v1.44.0.
#6086 Updates golang.org/x dependencies (crypto to v0.53.0, net to v0.56.0, term to v0.44.0).
#6061 Updates golang.org/x/sync to v0.21.0.
#6030 Updates github.com/tidwall/gjson to v1.19.0.
#6029 Updates github.com/mccutchen/go-httpbin/v2 to v2.23.0.
#6063 Updates github.com/mattn/go-colorable to v0.1.15.
#6062 Updates the Golang Docker image to 1.26.4.
#6084 Updates the Alpine Docker image to 3.24.0.
#6027 Updates the Debian Docker image to trixie-20260518.

External contributors

A huge thank you to the external contributors who helped during this release: @nightt5879, @Reranko05, @rohan-patnaik, @immanuwell, and @Anuragp22! 🙏

Grafana k6 release notes on Grafana Labs

Version 2.3.0 release notes

Version 2.3.0 release notes

New features

Run selected scenarios #6360

Run a script once with --once #6338

Keep metrics grouped across asynchronous calls #6340, #6341, #6342, #6343, #6344

Fetch missing TLS certificates #6137

Static labels for Prometheus remote write #6071

Nanosecond log timestamps #6310

WebSocket ready-state constants #6306

Encode bytes and compare sets with JavaScript built-ins #6382

Read the execution result before k6 exits #6388

UX improvements and enhancements

Bug fixes

Maintenance and internal improvements

External contributors

Version 2.2.0 release notes

Version 2.2.0 release notes

Breaking changes

New features

k6 cloud run --local-execution streams logs to Grafana Cloud #6171

Connect to a running browser with chromium.connectOverCDP() #6165

TextEncoder and TextDecoder globals #6182

WritableStream in k6/experimental/streams #6132

k6 cloud load-zone list command #6142

Configurable handleSummary() timeout #5854

New experimental feature flags: merge-run-tags and freeze-env

Version 1.7.1 release notes

Version 1.7.1 release notes

Maintenance and internal improvements

Version 1.7.0 release notes

Version 1.7.0 release notes

Breaking changes

New features

Automatic resolution for subcommand extensions #5664

Roadmap

Version 1.6.0 release notes

Version 1.6.0 release notes

Breaking changes

New features

Configurable default stack for Cloud commands #5420

k6 deps command and manifest support #5410, #5427

Browser module: frameLocator() method #5487

Browser module: goBack() and goForward() navigation methods #5494

Browser module: Request event handlers #5481, #5486

Crypto module: PBKDF2 support #5380

WebSockets module is now stable #5586

Console logging: ArrayBuffer and TypedArray support #5496

Configurable TLS version for Experimental Prometheus output #5537

A new TOTP library k6-totp

Introducing mcp-k6: AI-assisted k6 script writing mcp-k6

Roadmap

Version 1.5.0 release notes

Version 1.5.0 release notes

Breaking changes

Breaking changes for experimental modules

New features

page.waitForEvent() #5478

locator.pressSequentially() #5457

console.log() Deep Object Logging #5460

experimental/websockets - Close Code and Reason Support #5376

Subcommand Extension Support #5399

DNS Resolver Access #5421

Machine-Readable Summary Format #5338

URL-Based Secret Management #5413

Roadmap

Deprecation of First Input Delay (FID) Web Vital

Action required

Version 1.4.0 release notes

Version 1.4.0 release notes

Breaking changes

Breaking changes for experimental modules

Breaking changes for undefined behaviours

New features

OpenTelemetry output graduation #5334

page.waitForRequest #5330

page.unroute(url) and page.unrouteAll() #5223

locator.evaluate and locator.evaluateHandle #5306

New officially supported k6 DNS extension

Run a script once with `--once` #6338

`k6 cloud run --local-execution` streams logs to Grafana Cloud #6171

Connect to a running browser with `chromium.connectOverCDP()` #6165

`TextEncoder` and `TextDecoder` globals #6182

`WritableStream` in `k6/experimental/streams` #6132

`k6 cloud load-zone list` command #6142

Configurable `handleSummary()` timeout #5854

New experimental feature flags: `merge-run-tags` and `freeze-env`

`k6 deps` command and manifest support #5410, #5427

Browser module: `frameLocator()` method #5487

Browser module: `goBack()` and `goForward()` navigation methods #5494

`page.waitForEvent()` #5478

`locator.pressSequentially()` #5457

`console.log()` Deep Object Logging #5460

`experimental/websockets` - Close Code and Reason Support #5376

`page.waitForRequest` #5330

`page.unroute(url)` and `page.unrouteAll()` #5223

`locator.evaluate` and `locator.evaluateHandle` #5306

A new summary mode `disabled` has been introduced to replace the “no summary” option #5118

The `legacy` summary mode has been deprecated #5138

`locator.locator` #5073

`locator.contentFrame` #5075

`frameLocator.locator` #5075

`locator.boundingBox` #5076

`frame.getBy`, `locator.getBy`, `frameLocator.getBy*` #5105, #5106, #5135

`page.waitForResponse` #5002

Add `page.getByRole` API #4843

Add `page.getByLabel` #4890

Add `page.getByPlaceholder` #4904

Add `page.getByTitle` #4910

Add `page.getByTestId` #4911

Add `page.getByText` #4912

Add `page.route` #4953 #4961, #4971, #4985

Add `locator.all()` #4899

Add `waitForURL` in `frame` and `page` #4917, #4920

Remove experimental `k6/experimental/webcrypto` module #4851

New `count` method for the browser module’s Locator API #4797

New `nth`, `first` and `last` methods for the browser module’s Locator API #4825

`--template` and `--project-id` flags for `k6 new` command #4153

New `asObjects` option in `k6/experimental/csv` module #4295