Execution

The execution block on a Procedure controls how the runtime schedules Phases across workers and slots, and what happens the moment the first failure shows up. You get four levers (workers, slots, strategy, and on-fail behavior) and together they cover everything from a single laptop bench to a multi-slot production fixture.

For the conceptual model behind these levers, see Execution model.

Fields

The example below sets every field at once, so you can see how the block fits together before drilling into each lever.

execution:
  strategy: phase_first
  workers: 16
  on_first_failure: stop
  slots:
    - name: USB0
    - name: USB1

Workers

workers sizes the pool the runtime uses for parallel phases inside a single slot, so phases with depends_on serialize against their dependencies and the pool only matters for independent phases in the same stage.

execution:
  workers: 16

Match workers to CPU cores for CPU-bound tests, and bump it to 2-3 times the core count for I/O-bound tests (instrument calls, operator prompts, network calls) because the workers spend most of their time waiting. When every phase serializes on the same instrument, the worker count does not help, because the hardware is the bottleneck.

Slots

A slot is an independent test position, so when you declare multiple slots the same procedure runs in parallel against multiple Units on one bench. Each slot has its own unit identification, phase state, and outcome, and one slot failing does not affect the others.

execution:
  slots:
    - name: USB0
    - name: USB1
    - name: USB2

Slots are how production benches test four boards at once on a single fixture, so Plugs with scope: each get one instance per slot while plugs with scope: all are shared across slots.

Strategy

When you declare more than one slot, strategy controls how phases interleave across them, so you trade off shared-fixture throughput against per-slot timing.

The default is phase_first, because most multi-slot benches share at least one instrument and you want the runtime to keep that instrument busy.

On-fail behavior

on_first_failure controls what happens the first time any phase reports FAIL, so you decide whether the run keeps going or stops at the first sign of trouble.

• stop cancels the remaining phases for that slot (default).
• continue runs every phase to completion so you collect every measurement.

This setting only applies to FAIL outcomes, because unhandled exceptions, timeouts, and aborts always interrupt the Run. When the test infrastructure is in an unknown state, finishing on the same instrument is not trustworthy, so the runtime errs on the side of stopping.

A per-phase then.fail rule overrides this setting for that phase only, which is the right escape hatch when one phase is known to recover safely.

Run outcome

After every phase finishes, the runtime resolves the run outcome from the worst phase outcome across the slot, in the order below.

ERROR  →  ABORTED  →  TIMEOUT  →  FAIL  →  PASS

A single ERROR makes the entire run an ERROR regardless of how many phases passed, because an error means the test infrastructure failed and the data is not trustworthy. Analytics treats ERROR runs separately from FAIL runs so they do not pollute your pass-rate charts.