Debug a workflow

A debug run executes the workflow immediately from the editor and reports each task as it happens. Use it while building: it is the fastest way to see what a task actually received.

Starting and controlling a debug run

• Debug run starts the session.
• Pause stops at the next task boundary so you can inspect it before it continues. Continue lets it carry on.
• Step advances one task.
• Stop ends the session and discards it.

Hotkeys are shown beside each control. A debug session that sits idle pauses itself, so leaving the editor open does not keep spending credits. Starting it again begins a new session, which costs at least one credit again.

Changing a field for one run

While a session is paused, the pin beside a field overrides that field for this run only — whether it holds a plain value, a reference, or text containing one. Nothing about the workflow changes, and the pin disappears when the session ends.

A pin reaches only a task that has not run yet. A task that has already run keeps the value it ran with. To make a change permanent, edit the field and save; it takes effect the next time you debug the workflow.

When a run suspends

A run that waits for something outside the workflow — an approval, an input, a retry — shows as Suspended. It keeps its progress and resumes when the answer arrives. The run history shows the same state for scheduled and webhook runs.