After four k6 instances each run one execution segment, what does core k6 not do for you?
answer
- the split is exact, the merge is missing
- nobody is in charge of the fleet
- same expression, a quarter of the samples
- four summaries, four output streams
basics
~10 sCore 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.
solid answer
~50 sThe segmentation flags split a plan; nothing in core k6 splices the outcome back together. There is no primary or coordinating instance — every process is an ordinary `k6 run` that knows only its own segment and the shared sequence. Each instance loads the same script, so each evaluates the same `thresholds` expression, but against only the quarter of the samples it produced, so no instance's verdict covers the whole run and k6 emits no combined one. Each also writes its own `--out` stream and its own end-of-test summary, with nothing marking which quarter produced which samples. The division itself is exact — the shares sum to the scripted totals — but collecting the streams, deciding the fleet-level verdict and distinguishing the instances are all outside core k6, which is the gap the k6 Operator's `TestRun` `parallelism` exists to fill.
go deeper
Remember the headline: k6 splits the work across instances but never gathers the results back, so each process reports only on its own share.
Explain that every instance loads the same script and so evaluates the same threshold expression, but against only its own samples, and that each writes its own output stream and summary.
Show what you would put around the fleet: a destination all instances write into, something that identifies which instance produced which samples, and an explicit place where the fleet-level verdict is formed.
Decide whether the coordination gap is worth building on top of the flags at all, or whether an orchestration layer such as the operator should own fan-out and collection so that teams never assemble a fleet by hand.
## What the flags actually promise `--execution-segment` and `--execution-segment-sequence` divide a **plan**. Given a segment and the shared sequence, each k6 process works out its own share of the VUs, the iterations and the arrival rate, and runs it. That is the entire contract. In k6 v2 there is no second half where the pieces come back together. The segment type's own design notes make the intent explicit: the point of describing a share as a rational slice of `(0, 1]` is that an instance needs to know **only** its own segment and the sequence to compute its work reproducibly — so nothing has to schedule it from a master node. The strength is also the limit. ## The three things core k6 will not do | you might expect | what core k6 does | |---|---| | a primary process that starts, paces and stops the fleet | nothing — every process is an ordinary independent `k6 run` | | thresholds evaluated over the combined samples | each instance evaluates its own `thresholds` against only the samples it produced | | one end-of-test summary for the whole test | four summaries, one per process, each describing a quarter | Add the outputs: each instance writes its own `--out` stream and its own summary, tagged with nothing that identifies which quarter it was. Whatever joins them is yours to build. ## Why the threshold point bites hardest This is the one candidates get wrong. A script carrying a threshold does not stop carrying it when you segment the run — all four instances load the same script, so all four evaluate the same expression. Each one just evaluates it against a quarter of the traffic. No instance's verdict covers more than its own segment, and k6 emits nothing that covers all four. Three consequences follow: 1. **Each process decides its own fate independently.** One instance can finish reporting a breach while the other three report none, and k6 never produces a fifth, test-level verdict, because no process is in a position to compute one. 2. **Nothing carries a sample from one instance to another.** k6's metrics engine is per-process, so an instance's threshold expression can only ever be evaluated over the samples that process emitted. 3. **Nothing warns you.** k6 does not detect that it is one of several segmented instances, because it genuinely cannot — no instance ever learns that the others exist. A fourth consequence is procedural rather than technical: because the flags are ordinary CLI arguments with no side effects beyond this process, a segmented run looks in every log exactly like an ordinary single-machine run. Nothing in an instance's own output says it was one of four, so the only record that the four belonged together is whatever launched them. ## What you still get for free The split itself is exact and worth trusting: the per-instance shares of every scaled count add back up to the scripted total, and the striped index assignment means the four instances between them cover the planned work once and only once. Segmentation is a correct division. It is only the merge that is absent. ## Working with the gap - **Send every instance's samples somewhere that can hold them together.** Core k6 hands you per-instance streams; a single destination that all four write into is what turns them into one dataset. - **Decide the fleet-level verdict outside k6.** The supervising process — the CI job, the operator, the script that launched the four — is the only place that sees all four results. - **Tag the instances so the streams are distinguishable.** Nothing in k6 marks a sample with the segment that produced it, so if you need to tell quarter two from quarter three you must add that yourself when you launch. - **Keep the sequence identical everywhere.** The division is only exact if all four instances computed it against the same partition. - **Expect four exit statuses, not one.** Each process reports on its own segment, so the supervising job has four results to interpret rather than a single test-level one. - **Do not read a single instance's summary as the test's summary.** It describes one quarter of the planned work, and it never says so. ## The exception that proves the rule Grafana's k6 Operator exists precisely because of this gap: a `TestRun` with `parallelism: 4` fans one script out to four runner instances with an equal segment each, and takes on the coordination and collection that core k6 leaves out. Reaching for something above k6 is the expected answer here, not an admission of defeat — but the split itself is still done with the same two flags underneath.
- All four segmented k6 instances report their thresholds as passing. Has the test passed?Not necessarily, and k6 has not claimed it has. Each instance judged the same expression against a different quarter of the samples, so four local verdicts are four separate statements. The fleet-level conclusion has to be formed outside k6, by whatever supervises the four processes.
- Can one segmented k6 instance tell that the other three exist?No. An instance knows its own segment and the sequence it was given, which is enough to compute its share, and nothing more. There is no discovery, no handshake and no channel between processes, which is exactly why the design needs no coordinator.
- Does anything in a k6 sample say which execution segment produced it?No. The segment is not carried as a tag, so four instances writing into one destination produce indistinguishable samples unless you add something identifying at launch time. If you need per-instance attribution, arrange it yourself when you start each process.
saying these in an interview costs you the question
- Says one instance acts as primary and drives the others
- Expects thresholds to be evaluated over the combined samples
- Expects a single merged end-of-test summary
- Assumes the sequence flag enables coordination between instances
- Thinks four local passes compose into a test-level pass
- Expects samples to carry their segment automatically