Execution Lifecycle

State Transitions

QUEUED ──> ASSIGNED ──> RUNNING ──> COMPLETED
  |            |            |
  v            v            v
FAILED      FAILED       FAILED
                            |
                            v
                         STOPPED

Stale Execution Handling

A background job runs periodically to detect stale executions:

Condition	Action
QUEUED, no runner available within the configured window	Mark FAILED
ASSIGNED, runner OFFLINE past the grace window	Re-queue once, then FAILED
RUNNING, runner OFFLINE past the grace window	Mark FAILED

Retry model

Retries are applied at two distinct layers. Neither retries failed workflow logic; both protect the execution against infrastructure-level disruption.

Layer	Behavior
Queue level	Bounded retries with exponential backoff if the queue worker fails to assign the execution (for example, no Runner available, transient Redis error).
Execution level	One automatic re-queue if the assigned Runner goes OFFLINE while the execution is still in the ASSIGNED state. After re-queue, normal assignment rules apply.
Trigger level	No automatic retry. A failed execution is not retried from its trigger. To re-run, fire the trigger again or run the workflow manually from the Hub.

Performance metrics

Each execution records CPU average / peak and memory average / peak, sampled on the Runner and included in the final status report.

Was this page helpful?

A quick signal helps us prioritise improvements.