Skip to content
Docs
flero.ai

Execution lifecycle

An execution is one run of a workflow. It starts with a trigger fire, moves through a sequence of states, and ends at a terminal state. This page maps the journey.

The state machine

   ┌──────────┐
   │ pending  │  ← queued, waiting for a worker
   └─────┬────┘
         ▼
   ┌──────────┐
   │ running  │  ← currently executing
   └─────┬────┘
         ├─────────────────┬─────────────────┬─────────────────┐
         ▼                 ▼                 ▼                 ▼
   ┌──────────┐    ┌──────────┐      ┌──────────┐      ┌────────────────┐
   │ success  │    │  failed  │      │timed out │      │waitingForInput │
   └──────────┘    └──────────┘      └──────────┘      └────────┬───────┘
                                                                 │
                                                                 ▼
                                                          (back to running
                                                           after resume)

   ┌────────────┐
   │ cancelled  │ ← user pressed Stop at any point during pending or running
   └────────────┘

Terminal states (run is finished, won't change): success, failed, cancelled, timeout.

Non-terminal: pending, running, waitingForInput.

The states in detail

Pending

The trigger fired. The execution row has been written to the database. Now it sits in the queue (RabbitMQ) waiting for a worker to pick it up.

Typical duration: milliseconds to seconds. Longer means the workers are saturated, see Monitoring dashboard.

Running

A worker has the execution. It's evaluating nodes one at a time, in topological order.

Typical duration: depends entirely on what the workflow does. From milliseconds for an "if/log" to many minutes for big data sync workflows.

Success

The workflow reached its terminal state, either a Terminal node, or simply ran out of downstream nodes. Final output is captured. Execution row is closed.

Failed

A node threw an exception that wasn't caught (no Error Handling node, no continue on fail). The workflow's error policy setting decides whether this propagates to overall failed status.

The failure is recorded with the failing node, the exception type and message, and a stack trace (developer-facing, in the inspector's "Raw" tab).

Cancelled

Someone clicked Stop, or the API was called with a cancel request. The currently executing node is allowed to complete; no further nodes run.

Timeout

The workflow exceeded its executionTimeout (default 5 minutes; configurable in workflow settings). The execution is force-stopped.

WaitingForInput

A node (typically Approval) paused. The execution is durable, workers can be restarted and the wait continues. When the approver responds, the workflow resumes.

There's no timeout on waitingForInput by default; approvals can sit for days. The Approval node has its own timeout setting if you want one.

Sub-state: per-node statuses

Inside a running execution, each node has its own status:

Status Meaning
pending Not yet reached
running Currently executing
success Completed cleanly
failed Threw an exception
skipped Intentionally not run (e.g. on the wrong branch of an If)
disabled Marked disabled by the user
waiting Paused (approval, delay, sub-workflow)

You see these as the colours on the canvas during a live run, and in the timeline on the execution detail page after.

What's stored

For every execution:

  • Execution ID (UUID).
  • Workflow ID and version.
  • Trigger metadata (which trigger, what input).
  • Start time, end time, duration.
  • Final status.
  • Per-node timeline: status, start / end, input, output, errors.
  • Final output (terminal node).
  • Cost metrics (tokens, API calls, $).
  • Worker / region info.

Stored for the retention period configured in workspace settings (default 30 days). Older executions are purged.

Sandbox executions

A run made in sandbox mode is tagged sandbox: true and stored separately from production execution history (unless you opt to mix them). They have all the same state transitions and metadata but are filtered out of "real" execution counts in the monitoring dashboard.

Tips & gotchas

  • pending longer than 30 seconds usually means the queue is backed up. Check the dashboard, scale workers.
  • waitingForInput is not stuck. Approvals can sit indefinitely. To unstick, find the run in /logs, then resolve the approval in /approvals.
  • Execution IDs are immutable and unique, safe to share in tickets ("see exec abc-123 for repro").
  • Storage cost scales with retention × executions per day. Set retention deliberately. 30 days is generous for most teams; compliance regimes may want longer.

Found something out of date? This page lives in the Flero docs content set.