k6

Nothing halts. k6 records the failure on its built-in checks metric, check() returns false, and the iteration carries straight on to the next statement. The run's exit status is unaffected.

k6's check(), from the k6 module, has the signature check(val, sets, [tags]): a value, an object whose keys are check names and whose values are conditions called with that value, and optional extra tags. It returns a boolean.

k6 exits with code 99 when at least one threshold is breached, and 0 when they all hold. That single integer is the whole machine-readable verdict a CI job reads; the printed summary is for humans.

k6's built-in checks metric is a Rate, and the only aggregation a Rate threshold accepts is rate, which is a fraction from 0.00 to 1.00 rather than a percentage. So rate>90 is unreachable; write rate>0.9.

The braces create a sub-metric: k6 registers a filtered copy of http_req_duration that receives only the samples whose tags contain status:200, and evaluates the threshold against that copy instead of the whole metric.

In k6 v2, rate is how many iterations the executor starts during each timeUnit period, timeUnit is that period (default 1s), and duration is how long the scenario keeps starting them.

k6 turns root vus and iterations into a single scenario named default that uses the shared-iterations executor, so iterations is the total across all VUs. A root duration set alongside them becomes that scenario's maxDuration.

k6's constant-vus executor holds a fixed number of VUs for a set time and takes vus plus duration. ramping-vus moves the count through a schedule and takes startVUs, stages and gracefulRampDown. Neither accepts the other's keys.

preAllocatedVUs is the number of VUs k6 initializes before an arrival-rate scenario starts; maxVUs is the hard ceiling that pool may grow to mid-run. Omitted, maxVUs equals preAllocatedVUs, so the pool never grows.

k6 v2's ramping-arrival-rate takes startRate, timeUnit and stages. Each stage is a target plus a duration, and the target is the arrival rate in iterations started per timeUnit that k6 ramps to linearly by the stage's end.

k6's default exported function is the VU code: one virtual user runs it from its first line to its last, and that single start-to-finish call is one iteration. When it returns, the VU calls it again.

Everything outside a k6 lifecycle function is init code: imports, the exported options object, open() calls, metric constructors. k6 runs it once per virtual user, in that VU's own JavaScript runtime, before that VU's first iteration.

k6 calls setup() once per test run, after the init stage and before any virtual user starts. Whatever it returns is JSON-encoded once and handed to the default function and to teardown() as their first argument.

k6's SharedArray holds one copy of a data set per k6 process, not one per VU. Its loader runs once, k6 stores each element as a JSON string, and a VU gets a copy only on index access.

Anything needing VU state throws in k6's init context: http requests and batch, new http.CookieJar(), check(), group(), a custom metric's .add(), and exec.vu, exec.instance or exec.test.options. k6 attaches VU state only after init finishes.

k6 has no separate configuration file format. A k6 script exports an object named options, k6 reads it once at init, and its root keys - vus, duration, stages, scenarios, thresholds, tags - become the run configuration.

Every key in k6's options.scenarios object is that scenario's name, unique within the script and limited to letters, digits, underscores and dashes. Each entry must declare executor; exec, startTime, gracefulStop, env and tags all have defaults.

k6 resolves each option through five layers, lowest to highest: built-in defaults, a JSON config file, the script's exported options, a K6_ environment variable, then the command-line flag. The CLI flag always wins.

Because duration, iterations, stages and scenarios form one execution group in k6: any of the four set in a higher layer clears all four from every lower layer before the new value is applied.

startTime is an absolute offset from the start of the k6 run, not from the previous scenario's end. k6 launches every scenario at once and each waits out its own offset, so sequencing is arithmetic you do yourself.

k6 has four metric types: Counter, Gauge, Rate and Trend. Among the built-ins, vus and vus_max are Gauges, http_reqs and iterations are Counters, checks and http_req_failed are Rates, and every duration such as http_req_duration is a Trend.

k6/metrics exports Counter, Gauge, Rate and Trend. Counter sums added values and reports count and rate; Gauge keeps the last value; Rate reports the share of non-zero values; Trend keeps every value, giving avg, min, max, med and p(N).

k6 tags every sample emitted inside the callback with a group tag holding the full nested group path joined by ::, and it emits one group_duration Trend sample timing the callback.

http_req_duration equals http_req_sending plus http_req_waiting plus http_req_receiving. It excludes http_req_blocked, http_req_connecting and http_req_tls_handshaking, so connection setup never appears in it.

Constructing a k6 custom metric outside the init context throws "metrics must be declared in the init context". Only .add() may run inside an iteration; the k6/metrics constructors must sit at module scope.

The import throws straight away with a migration message: in k6 v2 the browser module has graduated and k6/experimental/browser was removed. Import browser from k6/browser instead, and await its calls.

k6 v2 ships its gRPC client at the stable path k6/net/grpc. The old k6/experimental/grpc name is registered only to throw a migration error on import, so the run aborts in the init phase before any VU starts.

k6 picks the encoding from the body's JavaScript type: a plain object is form-encoded as application/x-www-form-urlencoded. For JSON, pass JSON.stringify(payload) as the body and set Content-Type in the params headers object.

Set type to 'chromium' in a scenario's own options.browser block, so the full path is options.scenarios.<name>.options.browser.type. It is per-scenario, there is no root-level browser option, and 'chromium' is the only value k6 v2 accepts.

client.load() and client.loadProtoset() are init-only and error elsewhere with "load must be called in the init context". client.connect(), invoke(), asyncInvoke() and close() are the reverse: they raise an init-context error and must run inside an iteration.

An object whose keys are destinations and whose values are strings or ArrayBuffers. k6 sends the key stdout to standard output, stderr to standard error, and treats every other key as a file path it creates or overwrites.

k6 picks streaming destinations with the repeatable -o/--out flag or the K6_OUT environment variable. k6 v2 accepts json, csv, cloud, influxdb, experimental-prometheus-rw, opentelemetry, experimental-opentelemetry and web-dashboard; any other name aborts the run before it starts.

k6's summaryTrendStats accepts avg, min, med, max, count and p(N) for N between 0 and 100. It defaults to avg, min, med, max, p(90), p(95), and any list you set replaces that default entirely.

k6's json target writes newline-delimited objects: a Metric declaration, then a Point per sample with time, value and tags. The csv target writes a fixed header of metric_name, timestamp and metric_value, then tag columns. Both gzip on a .gz path.

k6's summaryTimeUnit fixes the unit every duration is printed in throughout the end-of-test summary. It accepts only s, ms or us; left unset, k6 picks a readable unit per value instead, so columns may mix ns, us, ms and s.

k6 resolves import specifiers the way a browser does, not the way Node does: it never appends .js, never falls back to index.js and never searches node_modules. The extension-less path names a file that does not exist, so the load fails.

The browser module graduated to k6/browser, and k6 v2 keeps the old path registered only as a stub that throws a migration message. The run dies while the script is loading and k6 exits 107.

k6 extensions are Go code compiled into the k6 binary; k6 has no runtime plugin loader. Either k6 provisions a prebuilt binary for you automatically, or you build one yourself with xk6 build --with.

k6 executes JavaScript on Sobek, a JavaScript engine written in Go, not on Node.js. It ships no Node standard library and no node_modules resolution, so a bare specifier like fs never resolves and loading the script fails during init.

k6 accepts both, but require() is k6's own implementation, not Node's: it loads built-in k6 modules, local files and remote https scripts only, it exists solely in the init stage, and it takes a specifier computed at runtime.

The grafana/k6 image sets ENTRYPOINT ["k6"], so appended arguments start at a k6 subcommand - here, run. The script lives on the host and not in the image, so the filename - makes k6 read it from standard input.

In k6, --execution-segment names the slice of total work one process runs, and --execution-segment-sequence names the full partition every process shares. Pass both, or each instance invents its own partition and the slices stop lining up.

Piping delivers one file and nothing else. k6 records a stdin script as /-, so relative imports resolve against the container's working directory, not the script's folder. Mount the directory and pass an in-container path instead.

A k6 test is a JavaScript module: imports, an exported options object, a default function. It reviews, diffs and merges like application code. The cost is that authoring and review require JavaScript, and the runtime is not Node.

Core k6 divides the plan but never rejoins the results. There is no primary process, each instance evaluates its thresholds against only its own samples, and each writes its own output stream and summary.