Blocking API call rejected in k6 init context

Direct answer

No. A blocking call such as sleep() cannot run in k6 init context. Move it to the default exported function or another per-VU function. Init runs once at startup before any virtual user exists, and k6 rejects blocking APIs there at runtime to prevent startup stalls.

What is confirmed

• Init code executes once at test startup, before any VU is created.
• The default function executes once per VU per iteration.
• k6 rejects sleep() and exec() from k6/exec in init with the runtime error 'blocking API call rejected in init context'.
• The error appears when running k6 run script.js, not during syntax checking.

Why k6 blocks it

Any call that blocks the VU event loop is prohibited in init because it would delay startup for every VU. Enforcement is strongest for sleep and exec; other blocking I/O may be allowed in some releases but is discouraged. Treat version-specific lists as assumptions until you check the release notes for your installed k6 version.

Timing after moving the call

No. Moving a blocking call from init to default changes the timing from once per test to once per VU per iteration. If you need a one-time startup delay, init cannot provide it with a blocking API. Use non-blocking setup in init and place per-VU delays in the default function.

Steps for this case

1. Check the installed version: k6 version. Compare it against the k6 release notes before relying on any version-specific exception.
2. Move the blocking call out of the top-level init scope into export default function.
3. Verify with a minimal script:

import { sleep } from 'k6';

export const options = { vus: 1, iterations: 1 };

export default function () {
  sleep(1); // allowed: pauses this VU iteration
}

1. Run k6 run script.js and confirm the init error does not appear and the pause happens per iteration.

One missing diagnostic detail that changes the recommendation: do you need the delay once per test or once per VU, and which executor are you using? Shared-iterations and per-VU-iteration executors behave differently, so the answer determines whether a default-function delay is acceptable or whether you need a different pattern.