v1.5.0

Compare Source

k6 1.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.

• #​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.

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();
}

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.

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.

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://quickpizza.grafana.com/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.

UX improvements and enhancements

• #​5458 Adds link to k6 extensions list in README for better discoverability.
• #​5366 Adds multi-source secret example for better documentation of secret management patterns.

Bug fixes

• #​5374 Fixes getBy* selectors when using quotes inside element names.
• #​5477 Fixes retry mechanism when frame has been detached.
• #​5461 Fixes panic when using nil page.on handlers.
• #​5401 Fixes panic when assigning to nil headers and cookies when the host is not found. Thanks, @​chojs23, for the contribution 🎉
• #​5379 Fixes browsers not being stopped in tests due to EndIteration.
• #​5439 Fixes loading files with spaces.
• #​5406 Fixes error messages after Sobek/goja changes.
• #​5381 Fixes version command JSON output for output extensions.
• #​5358 Fixes sending correct data when using ArrayViews in experimental/websockets.
• #​5488 Fixes a goroutine leak when performing CDP requests.

Maintenance and internal improvements

• #​5464 Adds ExecutionStatusMarkedAsFailed status for improved test execution tracking.
• #​5467 Refactors span error recording to avoid boilerplate code.
• #​5438 Unblocks the release workflow for package publishing.
• #​5436 Optimizes browser module allocations and improves CI stability.
• #​5411 Extends base config and stops updating go.mod toolchain.
• #​5408 Removes redundant GitHub Actions rule.
• #​5415 Updates Sobek dependency to latest version.
• #​5392 Updates OpenTelemetry proto module to v1.9.0.
• #​5357 Refactors browser module task queue usage.
• #​5378 Fixes TestNavigationSpanCreation test in the browser module.
• #​5482 Fixes tests and subcommand handling in the version command.
• #​5255 Updates gRPC module to v1.77.0.
• #​5506 Updates xk6-redis to v0.3.6.
• #​5473 Updates compression library to v1.18.2.
• #​5505 Removes close call in integration tests.
• #​5517 Removes SECURITY.md to sync with Grafana's org-wide security policy documentation.
• #​5528 Resolves CVE-2025-61729. Thanks, @​SimKev2, for the contribution 🎉

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.

v1.4.2

Compare Source

k6 v1.4.2 is here 🎉!

This is a patch release that includes:

• #​5439 Fix loading files with spaces in their paths
• #​5415 Updates Sobek to fix the unexpected token class issue

v1.4.1

Compare Source

k6 v1.4.1 is here 🎉!

This is a patch release that includes:

• #​5428 Reverts "Use new expect() syntax in script templates"

We'll re-introduce assertion-based templates down the road when the integration is seamless.

v1.4.0

Compare Source

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:

1. 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.
2. "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:

1. 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

2. Syntax errors were not reported as such, as the underlying esbuild parsing will fail, but won't be handled well. #​5127, #​5104

3. Propagating exit codes from a sub-process running the new k6. This lets you use the result of the exit code.

UX improvements and enhancements

• #​5307 QueryAll methods now return elements in DOM order. Thank you, @​shota3506, for the contribution.
• #​5159 Simplifies warning message for legacy config files.
• #​5343 Explictly marks the option's default values.

Bug fixes

• #​5242 Fixes cleanup errors on Windows for browser tests.
• #​5246 Fixes the support for TypeScript source code from stdin.
• #​5322 Fixes browser.newPageInContext bug where pages created in a non-existing browser context.

Maintenance and internal improvements

• #​5238 Browser: Fix early context cancellation in tests
• #​5347, #​5349 Browser: Move k6ext.Promise to the mapping layer.
• #​5340 Browser: Simplify page event iteration by using an iterator.
• #​5315, #​5311 Browser: Revamped page event listening internals for addition of new features and better maintainability.
• #​5339 Browser: Remove unused VU fields.
• #​5314 Browser: Refactor pattern matcher.
• #​5222 Browser: Fix linter errors and warnings.
• #​5207 Browser: Refactor and improve selector parsing. Thank you, @​elmiringos for the contribution.
• #​5313, #​5321 Update to k6provider v0.2.0 and update code to use the new API.
• #​4682 Update go-httpbin dependency to v2 and update tests to accommodate breaking changes.
• #​5309 Update cdproto dependency and fix syntax changes in browser module.
• #​5209 Update golangci-lint to v2.5.0 and fix related linting issues.
• #​5308 Format Go Doc comments. Thank you, @​shota3506 for the contribution.
• #​5184 Migrates Prometheus Remote-Write output configuration parsing to envconfig.
• #​5304 Bumps the minimum required Go version to 1.24.
• #​5214 Update release issue template after 1.3.0
• #​5303 Fixes code scanning alert no. 102: Incorrect conversion between integer types.
• #​5302, #​5244 Refactors Sobek out of business logic and into mapping layer for the browser module.
• #​5247 Refactors indirection out of locator.go.
• #​4234, #​5301, #​5300, #​5208 Updates renovate config.
• #​5355, #​5354, #​5353, #​5352, #​5351, #​5324, #​5293, #​5292, #​5291, #​5290, #​5288, #​5287, #​5286, #​5284, #​5283, #​5282, #​5268, #​5267, #​5266, #​5265, #​5258, #​5257, #​5256, #​5253, #​5252, #​5251, Updates dependencies.
• #​5216 Refactors TestPageOnResponse to fail fast on errors. Thank you, @​rMaxiQp for the contribution.
• #​5203, #​5201 Adds WinGet support to the project.
• #​5220 Switches from gouuid to google/uuid. Thank you, @​mikelolasagasti for the contribution.
• #​5344, #​5345 Uses .env context for ghcr login when publishing docker images.
• #​5331 Reports require calls during the initial loading of modules, instead for each call in all execution of all VUs.
• #​5218 Adds user AgnesToulet to the auto assign issue workflow.

v1.3.0

Compare Source

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('[email protected]');

// 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.

UX improvements and enhancements

• #​5117 Unifies unauthenticated errors for Cloud commands.
• #​5125 Changes a warn log to a debug when a worker type is used on a website under test.
• #​5111 Adds retries to actionability based APIs (locator) when elements aren't visible.
• #​5004 Removes undefined headers from route.continue/fulfill.
• #​4984 Adds link to documentation in k6 --help output. Thank you, @​Nishant891 for the change.

Bug fixes

• #​5079 Fixes version of k6 when it is built with xk6.
• #​5057 Fixes a panic on the deprecated k6 login cloud command. Thanks @​indygriffiths for reporting it!
• #​5059 Fixes group order in end of test summary when scenarios are used.
• #​5081 Fixes auto extension resolution only working if binary is called k6 after a fix in v1.2.2.
• #​5089 Fixes gRPC calls not using loaded types and erroring out, especially around the usage of Any.
• #​5071, #​5086, #​5163 Fixes click action in browser module when working in iframes and CORS.
• #​5084 Fixes a browser module issue when adopting elements from util to main execution contexts in Chromium.
• #​5178 Fixes a subtle metric labelling issue in Prometheus RW output.
• #​5200 Fixes a bug where clearTimeout would not recalculate the timer but instead will run the next timer earlier if it used to remove the earliest one. Thanks to @​kyriog 🙇.

Maintenance and internal improvements

• #​5165 Fixes arguments order for multiple {require|assert}.{Equal|NotEqual} and equivalent calls.
• #​5157 Fixes the test TestURLSkipRequest for Chrome 140+.
• #​5074, #​5078 Uses common.IsNullish through the code instead of other variants of it or custom helpers.
• #​5072, #​5107, #​5108 Update k6packager debian to latest LTS and fixes due to the update.
• #​5051, #​5052, #​5053 Adds tests and refactors getBy* and waitForURL implementations.
• #​5101 Updates times to nanoseconds to make tests less flakey in CI.
• #​5122 Migrates to use a new code signing process for Windows binaries instead of using the static code-signing certificate. Thanks @​martincostello for the contribution!
• #​5048 Updates release issue template after v1.2.0
• #​5046 Adds architecture overview and code authoring instructions for Claude Code and alike.

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.

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.

v1.2.3

Compare Source

k6 1.2.3 is a small patch with a couple of bug fixes

Bug fixes

• #​5099 Fixes auto extension resolution only working if binary is called k6 after a fix in v1.2.2.
• #​5098 Fixes gRPC calls not using loaded types and erroring out, especially around the usage of Any.

v1.2.2

Compare Source

k6 1.2.2 is a small patch release fixing a panic and two other smaller bugfixes.

Bug fixes

• #​5067 fixes a panic on the deprecated k6 login cloud command. Thanks @​indygriffiths for reporting it!
• #​5069 Fixes group order in end of test summary when scenarios are used.
• #​5070 Adds nullish check to the new getByRole and add tests for other getBy* APIs nullish checks.

v1.2.1

Compare Source

k6 v1.2.1 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

Note: An old xk6-browser repo v1.2.0 tag was pushed by mistake. It was left over on the machine since the merging of the two repos. As such it can not be used as a go module or installed with go install. For this reason v1.2.1 is released.

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).toBeDefine

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

---

This PR has been generated by [Renovate Bot](https://redirect.github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->