k6 Studio: recording browser flows into k6 test scripts

A recorder for the boring half of a load test

The README's summary of what the tool does is compact. With Grafana k6 Studio, you can quickly record a user flow in a browser, generate and inspect a HAR recording, customize your test script using predefined or custom rules, and test and debug your script to ensure it's working as expected.

The stated goal is to make generating k6 test scripts easier for anyone who would rather not write them by hand, in an interactive interface.

So the division of labour with k6 itself is deliberate. k6 is the load generator, a JavaScript runtime that executes your script against a target and reports metrics. k6 Studio is the authoring tool for the script that k6 will run. The output of Studio is a plain k6 script, not a Studio-specific artefact, which means the test does not depend on Studio being installed once it exists.

That is the key thing to understand about the tool's position. It is not a GUI for running load tests, and it is not a performance monitoring product. It sits one step earlier, at the point where somebody has to decide what the requests are, and it removes the mechanical work of writing them out.

The application is a desktop app for Mac, Windows and Linux, the primary language is TypeScript, and the licence is AGPL-3.0. The recent releases are v2.1.0 from 2026-08-11, v2.0.2 from 2026-08-05 and v2.0.1 from 2026-08-04, and the last push was on 2026-10-20.

Recorder, generator, validator

The How it works section divides the tool into three main components, and the division tells you where your time goes.

The Recorder is designed to generate a HAR recording of the user flow you want to test. When you start a recording, a new browser window opens, and every request is collected to generate the HAR file. You can also create groups during the recording to better organize your test script.

The Generator helps you create a k6 test script without having to write a single line of JavaScript. You can choose a HAR recording to automatically generate a valid k6 script, and then apply rules to fine-tune your script.

The Validator can help you test a k6 script by executing a single VU and single iteration test run to make sure that your script is working as intended.

So the flow is capture, transform, verify. The recording is the input, the script is the output, and the validator is the safety net between the two.

The groups feature in the recorder is worth pausing on, because it is the one piece of structure you add while recording. Without it, a recording of a checkout flow is a flat list of requests, and the generated script is a flat list of calls. With it, you are marking boundaries as you go, and the generated script inherits that grouping, which is what makes the result readable and therefore editable.

The validator's single-VU, single-iteration design is the other piece worth understanding. It is not a performance test, it is a correctness check, and it exists because a script that throws on the first request will fail in a load test in a much noisier way.

The recorder is a proxy, powered by mitmproxy

The mechanism behind the recorder is stated in a note in the README. The recorder uses a proxy to catch requests from the specific browser window, which is powered by mitmproxy.

That single sentence explains most of the recorder's behaviour, including its limitations. A proxy sits between the browser and the network and sees the traffic, which is how the HAR file is assembled. Because it is a proxy and not an extension, it needs a browser it can control, and the installation section makes that explicit.

Google Chrome or Chromium need to be installed on your machine for the recording functionality to work.

So there is a hard dependency on a Chromium browser that is not stated as optional anywhere, and a consequence that follows from the proxy design and shows up in the troubleshooting section: the proxy does not capture traffic sent directly to `localhost`. The documented fix is to assign a hostname to it and make requests through that name. To do that, modify the `hosts` file on your system, for example, `127.0.0.1 myapp`, and then you will be able to make requests in the browser at `myapp:8000/path`.

That is worth knowing before your first run, because it is the single most likely reason a recording comes back empty. It is also the clearest illustration of the trade the tool makes: a proxy sees everything the browser does, and in exchange it does not see requests that never leave the machine.

The mitmproxy dependency is also why the recorder opens a new browser window rather than attaching to the one you already have.

Rules are where the generated script becomes yours

The Generator is where the interesting work happens, because automatic generation from a HAR file only gets you so far.

You can choose a HAR recording to automatically generate a valid k6 script, and then apply rules to fine-tune your script. The README gives two examples: you can use a correlation rule to extract and replace a variable across your script, or even add custom JavaScript after each request.

The correlation rule is the important one. A recording captures literal values, so a session id or a token appears in the recording as a constant, and a script generated from that recording will send that same constant every time. A correlation rule captures the value from one response and substitutes it into later requests, which is the difference between a script that works once and a script that works.

The second example, adding custom JavaScript after each request, is a hook for the things a recording cannot know about. A check on a response body, a header that has to be derived, a log line, a cleanup step between requests.

Around the rules there is the rest of the generator's job. You can configure test options, such as the load profile for your test, see a preview of the script after all the rules are applied, and validate or export the script.

The preview matters as much as the rules, because it shows the script you are about to export with the rules already applied, so the rule work is visible before it becomes a file.

The export is the point at which Studio's involvement ends. What leaves the tool is a k6 script that you can commit, review and run anywhere k6 runs, which is what makes the authoring step a convenience rather than a dependency.

The validator shows requests, logs and checks

The Validator is described as helping you test a k6 script by executing a single VU and single iteration test run to make sure that your script is working as intended.

What it shows is what makes it useful rather than decorative. You can view the selected k6 script, all the requests and responses sent with the ability to inspect them in detail, the k6 logs, and also any k6 checks that are in your script.

That list covers the three things that go wrong in a generated script. A request that is malformed, which you catch in the request and response inspector. An error in the script logic, which you catch in the logs. And a check that is failing because the flow is not doing what you assumed, which you catch in the checks.

A virtual user in k6 is one concurrent execution of the script, so a single VU and a single iteration is the smallest possible run. That is exactly what you want for a correctness check, because a load test's failures are harder to read when the system is also under load.

The checks point is also the reason the validator is worth using rather than just running the script once by hand. A k6 check is an assertion inside the script, and seeing which ones failed, in the same view as the traffic that produced them, is faster than reading the output of a failed run line by line.

Two troubleshooting cases worth knowing in advance

The Troubleshooting section has three entries, and two of them will save you time on your first run.

The first is the localhost problem described above, where the fix is a line in the hosts file.

The second is a Proxy failed to start error, and the fix is platform-specific. If you're on a Mac, make sure you're not running the Grafana k6 Studio application from the Downloads folder. If that's the case, close the app, move the application file to the Applications folder, and start the app again.

That is a macOS quarantine and translocation behaviour rather than a k6 Studio bug, and the reason it is in the documentation is that it produces an error message that suggests the proxy itself is broken.

The third entry is where the logs live, which is what you need when you are about to file an issue:

- on Mac: `~/Library/Logs/k6 Studio/k6-studio.log`
- on Windows: `%USERPROFILE%\AppData\Roaming\k6 Studio\logs\k6-studio.log`
- on Linux: `~/.config/k6 Studio/logs/k6-studio.log`.

And the instruction for reporting problems is to include a tail of your log file when opening an issue.

There is also a support section that says the same thing in a different way: if you have any issues with Grafana k6 Studio, would like to report a bug, or suggest new features, open a ticket on the repository's issue tracker.

One more thing to know before you install. By default, Grafana k6 Studio collects anonymous usage data to help us improve the product through data-driven decisions, and the documentation link for usage collection is in the README. It is on by default, and that is worth a decision from whoever owns the policy rather than a discovery later.

An Electron app with a bundled k6 and eight Vite configs

The Development environment section shows how the application is put together, and the detail that matters most for an evaluator is how k6 itself gets into the product.

This repository currently loads k6 from packaged resources, not from a `PATH` lookup or env var. If you need to test with a custom k6 build, replace the bundled binary in `resources` before packaging, with the Linux path given as `resources/linux/x86_64/k6`.

So Studio ships the k6 binary rather than depending on a k6 installation on the machine, which means the validator and the export step always run the same k6 version that the project chose, and a user does not need k6 installed to try the tool.

The package scripts show the rest. The application is built with Electron Forge, with start, package, make and publish mapped to electron-forge commands, and the start script passes a remote debugging port, `electron-forge start -- --remote-debugging-port=9223`, which is how the Chrome DevTools Protocol client is wired in. There is a script that generates that client from a TypeScript source, `gen:cdp`, and a postinstall step that installs k6, `node scripts/install-k6.js`, with a separate script to update the k6 version and a k6-versions.json file at the root that records them.

Quality tooling is Vitest for unit tests, Playwright for end to end tests, oxlint for linting, oxfmt for formatting and tsgo for typechecking, with husky handling the commit hooks. The build side has seven separate Vite configurations, one each for the main process, preload, renderer, browser, script, replay and k6-testing targets, which is the usual shape for an Electron app with several distinct runtime contexts.

Producing a local packaged build needs two environment variables set first:

export SENTRY_DSN="sentry"
export NODE_OPTIONS="--max_old_space_size=8192"

pnpm install
pnpm package

And `pnpm make` instead of `pnpm package` produces installable artefacts such as .deb and .rpm, with the packaged app directory written to `out/` and the installer artefacts to `out/make/`.

The AGPL-3.0 licence and the presence of release-please configuration, a CODEOWNERS file and a catalog-info.yaml all point at a project run under a company's release process rather than a hobby.

Editorial conclusion

k6 Studio fits a performance engineer who knows what a k6 script should do but would rather not hand-write the first version of it, since recording a flow and editing the generated script is faster than writing requests from scratch and the result is a script you own afterwards. It is the wrong choice if you want a scripting-first workflow with no browser involved, since the recorder is the entry point, and the wrong choice in an environment where the anonymous usage collection is not acceptable, because it is on by default. Verify first that Chrome or Chromium is installed, since the recorder needs one, that your target is reachable by hostname rather than by localhost, because the proxy does not capture localhost traffic, and whether the AGPL-3.0 licence and the bundled k6 binary suit your distribution model.

Frequently asked questions

Official sources

1. grafana/k6-studio on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases