Concurrency Limits

Concurrency Limits control how many concurrent cloud browser executions can be executed at once by the team.

This option is set by default at 5. If the team has a paid license, this can be increased up to 100 in the Billing UI.

How It Works

Browser runs can be triggered via the Dashboard, UI, API, or New Pipeline Executions.

If the runs is triggered by the Reflow CLI, the browser runs executes locally, and no units of the concurrency limit are used.

If the run is triggered in any other way, the browser runs will be executed on the cloud.

How runs are scheduled

If any existing browser instances are available, the run will be immediately scheduled to run on these. This can be observed by a triggered run executing immediately, without a pending stage.

Runners are kept alive and waiting for commands up to 5 minutes from the last completed execution.

Else a new cloud runner will be provisioned to execute the test, depending on the team's concurrency limit:

When not exceeding the limit

When the team's concurrency limit is not exceeded, a new cloud runner is immediately provisioned for the test. This may take approximately 1 minute to become available. The concurrency limit will be decreased the moment that the runner starts provisioning.

When at the currency limit

When the team's concurrency limit is at its maximum, new runs will be queued until the existing ones are completed. The queue is drained from the oldest run first. If the queue gets so long that runs have been pending for over 1 hour they time out, and will need to be manually re-run.

Disabling Runners

Manually setting the concurrency limit to 0 will disable provisioning of new cloud runners.