Skip to main content

Execution queue & concurrency

msg.ZenTestAI does not necessarily start a test the moment you click Execute Test. Depending on how many other executions are already running in your tenant, the new run may queue behind them or, in some cases, be marked as Failed (Blocked) by a parallel-execution rule. This page explains the seven statuses, what the queue looks like in the UI, and the policies that decide when a run actually starts.

The seven statuses​

Every test execution moves through a subset of these seven statuses:

StatusTerminal?Meaning
InitialnoThe execution has been created but the runner has not yet picked it up. Most runs go through this for less than a second.
QueuednoThe runner has acknowledged the execution but cannot start it yet because the tenant's parallel-execution limit is currently reached. Will start automatically when capacity frees up.
RunningnoCurrently executing. Steps are being processed and screenshots streamed.
PassedyesFinished — every step in every variant passed.
FailedyesFinished — at least one step in at least one variant failed.
CancelledyesA user clicked Cancel before the run finished. Steps that had already completed keep their individual statuses.
Failed (Blocked)yesCould not run because a parallel-execution rule prevented it (e.g. another execution against the same target was still in flight when this one's window expired).

A status is terminal when no further state change is possible without a rerun. The Rerun and Delete actions appear only on terminal statuses; the Cancel action appears only on non-terminal ones.

Each status renders as a coloured tag in the Execution column of the Executions list and in the header of the detail view.

Parallel-execution policy​

A tenant has a maximum number of concurrent runs configured at the platform level. When the limit is reached:

  • New executions get the Queued status and wait their turn.
  • The queue is FIFO — earlier executions start first.
  • When a running execution reaches a terminal status, the oldest queued execution is promoted to Running.

The limit is set by your platform administrator and is not configurable per user. Typical values are in the single-digit range — enough to overlap a few independent tests without thrashing.

What the queue looks like in the UI​

In the Executions list​

Queued and Initial executions appear at the top of the Executions list (newest-first) with their respective coloured tags. There is no separate "Queue" tab or filter — to see only runs that are waiting, use the Filter popover and tick the Initial and Queued status boxes.

In the detail view of a queued run​

If you open a queued execution before it starts, the detail view shows informational overlays on the browser frame in place of a screenshot. The overlay text varies with the exact substate:

OverlayMeaning
Execution QueuedWaiting for runner capacity.
Test in queue (position N)Position in the platform-wide runner queue. Updates live as earlier runs finish.
Waiting for preceding testsWithin a multi-test execution (test set), this test is waiting for an earlier member to finish.
Analysing test stepsThe runner has picked up the execution and is parsing / validating the step definitions.
Test Starting…Browser is spinning up; first screenshot will arrive shortly.

These overlays are updated live via the Server-Sent Events stream — you don't need to refresh the page.

In test set executions​

For a test set execution, individual tests inside the set go through the same statuses independently. The parent execution is Running as long as at least one member test is non-terminal; it transitions to Passed / Failed / etc. when every member is done. The left panel shows each test's status icon — including the Waiting for preceding tests overlay for tests scheduled to run after others.

Cancelling a queued or running execution​

The Cancel button in the toolbar of the detail view (red stop icon) is available while the status is Initial, Queued or Running. Cancelling:

  • Removes a queued run from the queue immediately. It transitions to Cancelled.
  • Stops a running execution at the next safe checkpoint (usually within a second or two). Steps that already completed keep their statuses; the in-flight step is marked cancelled.
  • Cannot un-cancel. Once cancelled, the only way to "resume" is to Rerun, which starts a fresh execution.

A confirmation dialog protects against accidental clicks.

Failed (Blocked) — when does this happen?​

The Failed (Blocked) status is used when a parallel-execution rule explicitly prevents an execution from starting, rather than just delaying it. The most common case is:

  • A test set is configured (or the tenant is configured) so that the same test or test set may not run twice in parallel against the same target environment.
  • An execution sat in the queue long enough that the running execution it was waiting on did not finish before its timeout / window.
  • The new execution is then transitioned to Failed (Blocked) rather than being kept in the queue indefinitely.

In practice, you'll see Failed (Blocked) most often when:

  • A scheduled execution coincides with a long-running manual run that hasn't finished yet.
  • A pipeline triggers two consecutive runs against the same environment too quickly.

The fix is to either let the previous run finish, or to relax the parallel policy / target separation at the tenant level (administrator setting).

What a queued execution can and can't see​

While a run is Initial or Queued, the platform knows the test definition and the selected variants, but not yet:

  • Screenshots, video, logs (nothing has happened yet).
  • The runner version (the runner hasn't been selected yet).
  • AI model decisions.

So the detail view of a queued execution shows only the test list, the variants chosen, and the queue overlays — there is nothing more to inspect until it starts running.

Conversely, when the execution leaves the queue and starts running, the Server-Sent Events stream immediately starts pushing screenshots, logs and step updates without you having to refresh.

Auto-promotion and rerun​

When you click Rerun on a terminal execution, the new execution is added to the queue with the current rules — it does not jump ahead of other already-queued executions. So if your tenant is under heavy load, a Rerun click can sit in Queued for a while before starting.

The hotkey is Ctrl+p; it works on any terminal status, including Failed (Blocked) and Cancelled (the new execution gets a fresh status).

How long does Initial last?​

A few hundred milliseconds in a healthy system. If you see an execution stuck in Initial for more than a couple of minutes, it usually means the runner pool is unhealthy — report this to your administrator. The same applies to Queued runs that don't progress even when the queue ahead of them clears.

See also​