Skip to main content

Execution Statuses & Retrying

When you launch a workflow, its execution moves through a small set of statuses. Knowing what they mean — especially the two kinds of failure — tells you at a glance whether a run is fine, done, or something you can just retry.

The statuses​

  • queued — created, but the run hasn't been dispatched to the engine yet.
  • running — dispatched; the workflow engine is executing it.
  • completed — success; the result was handled and the workspace advanced.
  • failed_transient — failed for a reason outside the platform: an external service error, a crash, a guardrail self-termination, a missed callback, or an operator terminating it. Your configuration is fine.
  • failed_permanent — failed for a platform-side reason: the webhook couldn't be dispatched (e.g. a bad URL), or the plugin's result handler threw. Re-running with the same settings would fail the same way.

(There's also a cancelled status reserved for future use; it isn't produced in this version.)

Transient vs. permanent — the distinction that matters​

This is the practical heart of it. failed_transient means "the problem was external, your config is fine — a retry might just work." failed_permanent means "the problem is on the platform side — fix the configuration before trying again." When you see a failure, that label is your first read on what to do next.

Retrying​

Only failed_transient executions are retryable. From the execution's detail page you can retry it, and the retry reproduces the original conditions exactly — it re-uses the same four snapshots rather than re-reading your current configuration. That's intentional: a retry is meant to reproduce the run, not quietly change it. (Re-running with different configuration is a separate, future capability.) failed_permanent, completed, running, and queued executions are not retryable — for a permanent failure, correct the underlying config and launch a fresh run.