Load tests that live in the repo

Technology

K6 is a load generator that takes a JavaScript file as its input and a pass or a fail as its output. Virtual users are goroutines rather than browsers, so a single machine holds a lot of them, and the script describing the traffic sits in the repository next to the code it points at.

That shape is why we reach for it. Performance testing only stays honest when it runs on every build, and a load test with a threshold attached is something a pipeline can fail on. We name K6 alongside Gatling and JMeter in how we automate performance testing.

Monogram logo

Load tests

What K6 is good at, and what it cannot see

  1. Thresholds turn a report into a build gate

    A run prints percentiles either way. Declaring thresholds in the options block, a ceiling on p(95) and a maximum error rate, is what makes the process exit non zero when they are missed. That line is the difference between a performance report nobody reads and a check that blocks a merge.

  2. JavaScript, but not a Node runtime

    Scripts are ES modules, and K6 runs them on a Go binary with an embedded JavaScript engine rather than on Node. There is no install step at run time and no filesystem or socket API outside K6's own modules, so a library with Node dependencies has to be bundled ahead of time or replaced.

  3. It measures the protocol, not the page

    A virtual user issues requests. It does not parse HTML, run your bundle, or hydrate, so a page that is slow because of client side JavaScript still looks healthy here. The browser module exists and costs a real Chromium per user. No case study on this site walks through a specific run.