Runs & Monitoring
Inspect workflow executions live, review step-by-step timelines, resume suspended runs, and debug failures.
Every execution of a workflow - manual or triggered - produces a run. Runs are your window into what the automation actually did: which nodes executed, what data went in and out of each step, where things failed, and what the run is waiting on.
Run statuses
| Status | Meaning |
|---|---|
Pending | Queued; not started yet. |
Running | Currently executing. |
Suspended | Paused at a Suspend or User Input node, waiting on a human. |
Succeeded | Completed successfully. |
Failed | A step failed (and wasn't configured to continue on failure). |
Cancelled | Stopped manually before completion. |
Individual steps within a run report their own status: Running, Succeeded, Failed, or Skipped.
Live visualization
While a run is in progress and you have the workflow open, the canvas animates in real time - nodes light up as they execute so you can follow along without refreshing.
The Runs panel
Open the Runs tab in the builder to see the execution history: status badge, start time, completion time, and duration for every run.
Selecting a run opens its detail view with:
- A step timeline showing each node's status, duration, and attempts.
- Input and output snapshots for every step - the exact resolved configuration and resulting data, invaluable for debugging expressions.
- Error details for any failed step.
Resuming suspended runs
Runs waiting at a Suspend or User Input node appear as Suspended. From the detail view you can:
- Resume the run, optionally supplying a payload that becomes available to downstream nodes (e.g. results of an external action done outside the platform).
- Cancel the run if it's no longer needed.
Resume while steps are running
A suspended run can only be resumed once no steps are still in flight. If resume is unavailable, wait for active steps to finish first.
Failure behavior
Workflows are designed to fail gracefully:
- Continue on failure - each node has a toggle that lets execution proceed even if that node errors. The error is recorded under the node's context slot instead of failing the whole run - useful when an optional enrichment step shouldn't block the pipeline.
- Automatic retries - transient failures (network blips, rate limits) are retried internally with jittered backoff before a step is marked failed.
- Graceful stops - the Stop button requests a cancellation; in-flight steps are allowed to finish rather than being killed mid-execution.
Tips for debugging
- Start at the first red node in the timeline - failures cascade downward.
- Compare a failing step's input snapshot against what you expected; expression mistakes usually show up here.
- Check whether the failure is transient by looking at earlier attempts in the step's history.
- If data looked wrong before the failure, walk upstream to find where it diverged.