Skip to main content
Concurrency limits let you control what happens when multiple test runs are triggered at the same time. This is configured with two settings: scope and behavior.

Scope

The scope setting (test_run_concurrency_limit) defines the boundary within which only one run can be active at a time.
ValueWhat it means
noneNo limits — unlimited concurrent runs (default)
projectMax 1 active run per project, across all environments
environmentMax 1 active run per environment
branch_environmentMax 1 active run per branch + environment combination

Behavior

The behavior setting (test_run_concurrency_behavior) defines what happens when a new run is triggered while the concurrency limit is reached.
ValueWhat it means
cancel_previousCancel the in-progress run and start the new run immediately
queue_newKeep the existing run, queue the new run until capacity is available

How queueing works

When queue_new is enabled:
  • Only one run can be active (running) per scope at a time
  • If a new run is triggered while one is already running, it enters a Pending state
  • If another run is triggered while one is already pending, the older pending run is cancelled and replaced by the newer one
  • When the active run finishes, the most recent pending run is dispatched automatically
This “keep latest” strategy ensures you never waste resources running stale test runs.

Examples

ScopeBehaviorWhat happens
noneAll runs execute immediately, no limits
projectcancel_previousNew run cancels any running run in the project
environmentqueue_newNew run waits for the current run in the same environment
branch_environmentcancel_previousNew run cancels the running run on the same branch + env