Load Test Step Limits
A load test runs many virtual users in parallel, each firing requests as fast as the test allows. To keep that path fast and predictable, load test step scripts (Pre-Script and Post-Script on a step inside a spec) run in a smaller, sandboxed JavaScript engine instead of the full engine used everywhere else. This sub-section collects every limit that applies to that engine so you know what to expect.
These limits apply only to step scripts in a load test. Load test Before All and After All scripts run on the full engine and are not subject to any of the restrictions below.
Missing Globals
- •No fetch — load test step scripts cannot make outbound HTTP calls. If you need to hit an external API as part of the test, move the call to Before All (to seed data) or After All (to report results).
- •No setTimeout — artificial delays are not available. The test runner already controls pacing through the test-type configuration.
- •No top-level await — the script is executed synchronously. Any attempt to await something is a parse error.
Slightly Reduced at Surface
- •at.environment, at.flow, at.request, at.response — all work, with the same methods and the same semantics (pre mutable / post read-only) as the main engine.
- •at.response.timing exposes only the total field — the dns, tls, and ttfb breakdown is not available inside load test step scripts.
- •at.export is not present. Export only makes sense after a run has finished, so it lives in After All scripts — where the full engine is back.
What Still Works
Despite the limits above, the engine is a real JavaScript engine and the day-to-day script patterns all work:
- •console.log / info / warn / error — all four methods work, with the same 1000-character total cap.
- •Plain JavaScript — variables, control flow, Math, JSON.parse / JSON.stringify, string and array helpers, regular expressions.
- •at.flow.set / get — each virtual user has its own independent flow store, so values set in a step are visible to that same virtual user's later steps.
- •at.environment.set — environment changes still propagate, but remember that every virtual user will see them — use with care in a high-concurrency run.
When You Need Something the Step Engine Cannot Do
If your load test needs to make an external HTTP call, export a report, or do something async, do it from a lifecycle script instead:
- •Seeding test data or fetching a token → Before All. Make the call with await fetch, store the result in at.environment or at.flow, and every step will have access to it.
- •Sending a report or notification → After All. Build the payload from at.export.* and post it wherever it needs to go.
- •Cleaning up the test user or test data → After All with fetch.