Debugging basics

Debug a workflow on the canvas: start a debug run, read the results, find failures, and test parts of a workflow with mocks.

Debugging happens on the same canvas where a workflow is built. There is no separate debug view: a debug run starts from the canvas, the panel below the canvas shows the results, and changes are made on the canvas when an issue appears.

Starting a debug session

Run Debug (▶) in the bottom toolbar of the canvas starts a debug run, in every tool. If the trigger has inputs, a dialog asks for their values. In Studio Web, Debug at the top left of the toolbar does the same. A panel appears below the canvas, and the execution trace fills in as each node runs.

Stop debug ends the run explicitly, and any change to the workflow also ends it. The Flow canvas describes the debug controls and the panel below the canvas in full.

Reading the results

The Executions tab below the canvas has three parts, each answering a different question:

• Debug runs: the list of runs, with the name, duration, and age of each.
• Execution trace: every node that ran, in order, with timing and a success or failure indicator. Selecting a node in the trace highlights it on the canvas, and hovering over a node shows when it started and ended.
• Details: for a run, the Variables, Incidents, and Metadata tabs. For a node, the inputs it received and the outputs it produced.

The Incidents tab lists the errors of the run, grouped by node. Each incident names the node that failed and includes the error message. An unexpected stop is best checked there first.

The Variables tab shows runtime variable values in three sections: Inputs (values passed into the workflow), Outputs (values it produced), and Variables (internal workflow variables). Selecting a node in the trace shows the state at that point. A Filter variables field searches the values by name.

Identifying failures

After a debug run, each node on the canvas shows a success or failure indicator. The failed node is also marked in the execution trace, and the Incidents tab shows the error message.

The error object includes a message field (human-readable description) and a detail field (technical cause). The message field contains the user-facing failure summary, so it is the place to start.

Using mock nodes

A static mock tests part of a workflow in isolation. A node with a static mock doesn't run, and passes the mocked data to the nodes after it. This is useful when an earlier node is slow, needs credentials that are not available locally, or depends on external systems. The node's expanded view, which opens by double-clicking the node, has a mode menu in the Output column. Static mock replaces the real response with data that the nodes after it expect, and Generated has an LLM produce the response. Output mocking describes both.

Mocking multiple nodes at once lets the debug run focus on a specific section of the workflow.

Tips

• Execution trace first, incidents second: the trace shows the whole run, and the incidents show only what broke.
• Variable values reveal data mismatches: compare the data a node received with the data the next node expected.
• Mocking external dependencies enables faster iteration: mocking a node that calls an API or triggers an RPA process lets the logic be debugged without waiting on external systems.
• Small iterations are faster: one fix per debug cycle is more efficient than trying to fix everything in one pass.
• Descriptive node names improve trace readability: the trace and the incidents reference node names, and names that describe what a node does make traces easier to scan.

Next steps

• The Flow canvas: the debug controls and the panel below the canvas.
• Error handling: configuring error branches on nodes.
• Variables and data flow: how variables work across nodes.
• Community: ask questions and share workflows with other builders on the UiPath Forum.