Releases: grafana/xk6-dashboard
v0.7.12
xk6-dashboard v0.7.12 is here 🎉!
This patch release resolves security vulnerabilities, through upgrading:
viteto^4.5.14esbuildto^0.25.0tmpto^0.2.4
The following vulnerabilities have been addressed:
- CVE-2024-47068
- CVE-2024-45811
- CVE-2025-24010
- CVE-2025-46565
- CVE-2025-32395
- CVE-2025-30208
- GHSA-67mh-4wv8-2f99
- CVE-2025-31125
- CVE-2025-31486
- CVE-2024-45812
Other Changes
- docs: Add instructions for frontend development by @cristianoventura in #229
- fix: CONTRIBUTING.md broken link by @cristianoventura in #230
- Bump dashboard packages to address CVEs by @e-fisher in #235
New Contributors
Contributors
Assets 12
v0.7.11
xk6-dashboard v0.7.11 is here 🎉!
This patch release resolves one security vulnerability, through upgrading lerna to v8.2.4
The following vulnerability have been addressed:
v0.7.10
xk6-dashboard v0.7.10 is here 🎉!
This patch release resolves several security vulnerabilities, primarily through dependency updates.
The following vulnerabilities have been addressed:
v0.7.9
xk6-dashboard v0.7.9 is here 🎉!
This release is a prerequisite for the feature request in grafana/k6 to enable the web dashboard by default.
Changes
Gracefully Handle Default Port Binding Errors
When multiple k6 instances are run in parallel (e.g., in a CI environment), each instance tries to launch the web dashboard and bind to the default port, 5665. The first instance succeeds, but all subsequent instances fail with a "port in use" error. This fatal error terminates the test run, preventing parallel execution when the dashboard is active.
The solution
The dashboard's error handling for port binding now more flexible. Specifically, if a port binding error occurs on the default port (5665), the behavior is:
- A warning message is logged to the console, informing the user that the dashboard couldn't start on the default port.
- The error is treated as non-fatal.
- The k6 test proceeds to run normally, as if the dashboard were disabled for that specific instance.
This change makes the dashboard's behavior consistent with other k6 services (like the REST API) and would allow for the dashboard to be enabled by default in k6 without breaking parallel test execution workflows.
Downgraded spf13/cobra to 1.4.0
To maintain compatibility and continue the integration of xk6-dashboard with the main Grafana k6 repository, the spf13/cobra dependency downgraded from its current version (v1.9.1) to v1.4.0. This is to align with the version of spf13/cobra currently in use by Grafana k6.
Problem
The upstream Grafana k6 project uses an older version of the spf13/cobra library (v1.4.0). The current version in this repository (v1.9.1) creates a dependency conflict, which blocks the seamless integration of newer xk6-dashboard versions into Grafana k6.
Impact
As a direct consequence of this downgrade, the szkiba/docsme build-time tool, which is used for automatically generating the cmd/k6-web-dashboard/README.md file, will no longer be compatible.
Therefore, any future updates to the cmd/k6-web-dashboard/README.md file will need to be performed manually. This manual process will remain in effect until the spf13/cobra library is updated in the Grafana k6 repository.
v0.7.8
xk6-dashboard v0.7.8 is here 🎉!
This release is a prerequisite for the feature request in grafana/k6 to enable the web dashboard by default.
Changes
Gracefully Handle Default Port Binding Errors
When multiple k6 instances are run in parallel (e.g., in a CI environment), each instance tries to launch the web dashboard and bind to the default port, 5665. The first instance succeeds, but all subsequent instances fail with a "port in use" error. This fatal error terminates the test run, preventing parallel execution when the dashboard is active.
The solution
The dashboard's error handling for port binding now more flexible. Specifically, if a port binding error occurs on the default port (5665), the behavior is:
- A warning message is logged to the console, informing the user that the dashboard couldn't start on the default port.
- The error is treated as non-fatal.
- The k6 test proceeds to run normally, as if the dashboard were disabled for that specific instance.
This change makes the dashboard's behavior consistent with other k6 services (like the REST API) and would allow for the dashboard to be enabled by default in k6 without breaking parallel test execution workflows.
Downgraded spf13/cobra to 1.4.0
To maintain compatibility and continue the integration of xk6-dashboard with the main Grafana k6 repository, the spf13/cobra dependency downgraded from its current version (v1.9.1) to v1.4.0. This is to align with the version of spf13/cobra currently in use by Grafana k6.
Problem
The upstream Grafana k6 project uses an older version of the spf13/cobra library (v1.4.0). The current version in this repository (v1.9.1) creates a dependency conflict, which blocks the seamless integration of newer xk6-dashboard versions into Grafana k6.
Impact
As a direct consequence of this downgrade, the szkiba/docsme build-time tool, which is used for automatically generating the cmd/k6-web-dashboard/README.md file, will no longer be compatible.
Therefore, any future updates to the cmd/k6-web-dashboard/README.md file will need to be performed manually. This manual process will remain in effect until the spf13/cobra library is updated in the Grafana k6 repository.
v0.7.7
v0.7.6
xk6-dashboard v0.7.6 is here 🎉!
This is a maintenance release, changes:
- Updated k6 to v1.0.0
- Use shared GitHub workflows from xk6
- Updated tooling dependencies
go: 1.24golangci-lint: 2.1.6xk6: 0.19.2gosec: 2.22.4govulncheck: 1.1.4goreleaser: 2.9.0
- Added support for Development Containers
- Generate Makefile from
CONTRIBUTING.md
v0.7.5
xk6-dashboard v0.7.5 is here 🎉! This is an internal maintenance release.
(no bug fixes, no new features)
Breaking changes
Configuration customization from JavaScript code has been removed
Until now, the dashboard configuration could be customized with a JavaScript code. Supporting this feature after switching the JavaScript interpreter (goja to sobek) causes serious difficulties. Since this feature is rarely used, it is easier to drop it than to support it.
v0.7.4
v0.7.3
xk6-dashboard v0.7.3 is here 🎉! This release includes:
- Breaking Changes
- Bug Fixes
- Enablers
Breaking Changes
As of v0.49.0, k6 includes xk6-dashboard as a built-in output extension. The name of the built-in module is the same as was the output name (web-dashboard) registered by the extension. Therefore, if you try to use it as an extension (for example, a newer version), you will get the following error:
$ ./k6 run -o web-dashboard script.js
.
.
.
ERRO[0000] invalid output extension web-dashboard, built-in output with the same type already exists
From now on, the registered name of the extension is again the previously used dashboard. Thus, it is possible (for example, built with xk6) to use a version of the xk6-dashboard that is newer than the one integrated in k6. In this case, the dashboard name must be used as the output name.
$ ./k6 run -o dashboard script.js
Related issue
Bug Fixes
- xk6-dashboard no longer works as an extension
- Report charts remain empty with short test
- Increase tooltip text size
- Selected timeframe resets on next data refresh
Enablers
The following enhancements enable various future dashboard UI feature developments.
SSE Stream Optimization
Previously on the SSE stream, the snapshot and cumulative events are sent as JSON objects, where the metric names are the property names. The property values are also JSON objects, in which the property names are the names of the aggregation function (avg, min, max, etc.). This two-level object hierarchy has not caused any problems so far, the amount of data has been acceptable.
Until now, aggregate counting per tag is still supported, but by default it is only allowed for the group tag. It would be necessary to turn on the aggregate calculation for the url and name tags as well (per URL graphs, summary, etc.). With the previous SSE stream format, this would significantly increase the amount of data. This would have a direct impact on the k6 memory requirement, so it is a problem.
Based on measurements, it can be concluded that using a two-level array structure instead of the two-level object structure used in snapshot and cumulative events significantly reduces the size of the events and thus also the memory requirement.
Therefore, instead of the two-level object structure, a two-level array structure implemented in the snapshot and cumulative events. The packages/model package also updated so it hides SSE stream changes from the rest of the dashboard UI.
Related issues
- Adding a URL table panel to the timings tab
- Dashboards representing individual transactions' metrics rather than TOTALs
Thresholds Evaluation
The display of threshold values on the dashboard UI is greatly simplified if the SSE stream includes threshold expression evaluation results. If the evaluation of a threshold expression belonging to a metric fails, it is included in the new threshold event.
Related issue
Custom Metrics
In the various metrics tables, it is advisable to display the custom metrics before the built-in metrics, because the reader is likely to be more interested. This requires marking individual metrics on the event stream. The true value of the custom property indicates the custom metric.
Test Script Name
It is advisable to display the name of the currently running test script on the dashboard. Therefore, the scriptPath (script name) parameter has been added to the param event.