Find and fix issues using the run view in the workflow editor.
Open a run
- Open your workflow and switch the sidebar to the Runs tab to see recent runs.
- Filter the list by status (Running, Completed, Failed, Cancelled, Pending), pick a date range, or toggle Show debug runs.
- Click a run to open it in the Live tab. The clock button jumps to the latest run; keep Auto-follow on to track new runs as they start.
- Use the copy-link button in the run header to share a permalink to that exact run.
The Workflows list also shows each workflow's last run status, and its Activity sidebar carries the same run list and run view.
Start a run with inputs
When a workflow's Manual start declares inputs, Run now in the Workflows list opens a form before it starts the Current release. Each input gets a field for its type: text, a number, a switch for yes or no, a list of allowed values, one value per line for a list of text, a file upload for an Attachment input (several files for a list of them), and JSON for objects and other types. Fields start with the input's default, and Required marks the ones a run must have.
A blank field is not sent, so the input's default applies. The checks are the run's own: a missing required input, a value of the wrong type or one that is not allowed shows its reason under its field, nothing starts, and what you typed stays in the form. A file is stored as an attachment in your workspace when you start the run, and the input carries a reference to it.
In the editor, Test with inputs… shows the same form for a Manual start that declares inputs. Edit as JSON shows the input as one JSON object to edit or paste; turning it off puts the values back into the fields. The form stays open until the test run starts, and the next Test with inputs… opens with the values you used last.
Read the run
- The run header shows status, duration, who started the run, and which trigger fired. It also names the exact source the run executed: the Release (
Release v4), the main Draft (Main Draft), or a branch Draft (Branch "tuning" Draft). A Draft keeps changing, so the header adds the revision it ran (Main Draft · rev 7) — two tests of the same Draft at different revisions are different evidence. A Release has no revision and older runs recorded none, so those show the source alone. - The header states what the run is evidence of: Selected node, Subgraph replay, or Full workflow. A selected-node test on a Release is not a full run of that Release, and the header says so.
- Expand Inputs and Results to see the data the run started with and what it produced.
- Steps appear in execution order; steps that ran concurrently are grouped as parallel. Failed and running steps expand automatically, and the last step opens because it carries the run's result.
- Expand a step to view its inputs, outputs, timing, and errors. HTTP request steps show the response status, body, and collapsed headers.
- A step that called a provider (Jira, Gmail, Drive, Sheets, GitHub) has a Calls tab listing each request it sent, in order: method, URL, status, time and what it was for. Open a request to see its query, the body it sent and, for a failed request, the provider's answer. A step that runs once per item lists every item's requests. Credentials are never recorded.
- A failed step's Error tab names the error's type and lists what it carries, such as the transitions an issue does offer or the item that failed.
- Tool steps show their execution state and associated approval decisions in the run trace. A device's local consent and a workspace review are distinct decisions; either can be denied or expire before execution starts.
- While a run executes, nodes on the canvas highlight with their step status, and node ports show last-run values.
- A run can finish with partial errors: the run header lists which nodes failed even though the run completed.
Every run freezes its graph and execution envelope at admission: runtime, services, volumes, environment, defaults, workspace policy, trust posture, and credential contract. Later Draft edits, Publishes, Restores, Starts, or Pauses cannot change that run. A Retry creates a new linked run from the same frozen source, even if another Release is now Current. Disabled nodes and edges captured in the source remain visible for context but are excluded from the executable graph.
Waiting runs
- An Ask a person step suspends the run and shows a response panel in the run view — approve or reject, type a text answer, or pick from options. The run reads Needs approval or Needs your input, and the panel names who can answer. Answering resumes the run.
- A Wait step parks the run and resumes it automatically at the scheduled time. The run reads Waiting, and the run view, the Runs list and the workflow's Last run show when it resumes ("Resumes in 12m (04:27 PM)") in your timezone.
- A Run command step that started on your device reads Running on device and names the device until its result arrives.
- A Stop step ends the run early as a success; the run view notes that downstream nodes were not scheduled.
- A run can also be live without having executed anything yet. The run view says No node has started running yet. Several different waits produce that state and nothing on the run tells them apart, so the view names no cause. The run starts on its own once the runtime picks it up and there is nothing to retry, but the wait is not unlimited: it counts against the run's own timeout (30 minutes unless the workflow sets another), and a run that has still started nothing by then fails.
This suspension belongs to the individual run. It is separate from a workflow being Paused, which only blocks new production entries and does not interrupt existing runs.
Fix and re-run
- Adjust node settings and click Test (Cmd/Ctrl + Enter) to verify fixes against the autosaved Draft. Editor tests are debug runs by default.
- Use Retry Run in the run actions menu on a failed or cancelled run; the new run links back to the original and uses the original run's frozen graph and execution envelope.
- Use Cancel Run to stop a running or suspended run.
- Use Copy to Draft to replace the editable Draft with the graph a run executed — useful when the Draft has moved on since the failure. It replaces whichever Draft is selected, and the confirmation names it (main Draft or a branch Draft) before you commit. This does not change the Current Release or the Running/Paused state; Publish when the copied Draft is ready for production.
Test one node on an exact source
To reproduce a step against the exact release, branch, or Draft body without copying the graph, select that source in the editor, select the node, and use Test selected node (or Test reachable subgraph) in the node settings. Review the preview (source, scope, inputs, missing accounts, side effects) and press Start test. The resulting run is a debug run of that source: paused production stays paused and nothing is published. The run opens in the sidebar; the editor keeps showing the source you tested.
Tips
- Use a Manual start trigger for rapid iteration.
- Add Note nodes to document assumptions and expected shapes.
- Streaming steps (shell commands, coding agents, AI) show their output live in the step card while they execute.
Common issues
- API 401/403: re-authorize the Connection in Settings → Connections and verify credentials and permissions.
- Parse errors: inspect the response body in the step's details; ensure the payload is valid JSON.
- Run stuck in running: an external call may be hanging — check the step marked Live, or stop the run with Cancel Run.
Workflow run limits
Set Max active runs in Advanced settings. Excess batch starts queue and start in order after an earlier run releases its resources. Clearing the cap admits the queue. A first limit waits until runs started without a limit finish.
The run panel shows Queued — workflow limit reached, waiting time and its position when you can inspect the whole queue. Waiting is indefinite unless Queue wait limit (seconds) is set. That limit applies to new waits and fails a run that has not started in time; execution time starts after admission. Subflow and Loop children and hosted sessions continue to refuse a full cap.