Execution
Running flows, understanding results, and using iterations.
Running a Flow
Click the Run button in the Action Bar to execute all enabled steps in order. The button changes to Stop during execution, allowing you to abort at any time.
If iterations or parallel execution are configured, the button shows the count (e.g., Run (5x) or Run (10x)).
Run Options
Click the dropdown arrow (↓) next to the Run button to open the run options menu. This menu lets you fine-tune how your flow executes.
| Option | Description |
|---|---|
| Run with iterations | Opens a modal to set the iteration count. The flow runs N times sequentially — each iteration runs all steps in order, then the next iteration starts. When active, a badge shows the count (e.g., 5x). Disabled while Parallel execution is active. |
| Clear iterations | Resets iteration count back to 1. Only visible when iterations are set to more than 1. |
| Parallel execution | Opens a modal to set the parallel count (VUs). The flow runs as N concurrent virtual users, each executing the full step sequence in parallel — similar to a small load test. Disabled while Run with iterations is active. Iterations and Parallel are mutually exclusive. |
| Clear parallel | Resets parallel count back to 1. Only visible when parallel is set to more than 1. |
| Delay between steps | Opens a modal to set a delay (in milliseconds) between each step execution. Useful for rate-limited APIs. Current delay is shown below the option label. |
| Clear delay | Resets delay back to 0ms. Only visible when a delay is configured. |
| Stop on failure | Checkbox toggle. When enabled, the flow stops immediately when any step fails (request error or assertion failure). When disabled, all steps run regardless of failures. |
Tip: The dropdown is only available when the flow is not running. During execution, only the Stop button is active.
Multiple Iterations
Running a flow with multiple iterations executes the entire flow N times sequentially. Each iteration starts with a fresh copy of the Before All flow store — values you set in Before All (e.g., a shared auth token) persist into every iteration, but values extracted by steps within an iteration do not leak into the next one.
Use Cases:
- •Regression testing: Verify that your API returns consistent results across multiple runs. If iteration 3 suddenly fails while others pass, you've caught an intermittent bug.
- •Performance profiling: Identify response time patterns — the first iteration is often slower due to cold starts (server warm-up, DNS cache, connection pooling). Running 5-10 iterations reveals the true steady-state performance.
- •Stability testing: Check if intermittent failures occur under repeated load. A flow that works once but fails on iteration 7 may point to rate limiting, connection leaks, or resource exhaustion.
- •Load pattern observation: Compare response times across iterations to detect degradation trends — if each iteration gets progressively slower, the server may be under memory pressure.
Tip: Combine iterations with Delay between steps to simulate realistic traffic patterns instead of hammering the API as fast as possible.
Iterations vs Parallel — Which One?
Both options run the flow more than once, but they answer different questions. They are mutually exclusive in the UI — set one and the other is disabled.
| Mode | Behavior | When to use |
|---|---|---|
| Iterations | Runs the flow N times one after another. Iterations never overlap. | Stability checks, regression runs, response-time variance, anomaly detection. |
| Parallel | Spawns N concurrent virtual users (VUs). All VUs execute the full flow at the same time. | Quick smoke load tests, race-condition checks, concurrency-sensitive endpoints. |
For full-scale load testing with ramp-up, custom user profiles, and dedicated metrics, use the Load Testing module instead. Parallel here is meant for quick concurrency checks from inside the flow editor.