Debugging Workflows

Watch your workflow run, pause where it matters, and inspect the data flowing between steps.

Circuitry debugging works on two levels: watch the whole workflow execute live, and set breakpoints inside code to step through line by line.

See execution live

When a workflow runs, follow it on the canvas — each node shows its status (running, complete, error) and you can inspect the output of any node as data moves through. This makes it easy to spot where a pipeline goes wrong.

Run Log

Open it from Menu → Debug → Show Run Log (or the Run Log toggle in the top toolbar). It's a chronological, call-stack-ordered trace of every node that ran — timing, model, server, outcome, and (on click) the node's output. Agent tool calls (MCP servers, vector stores, procedures) are indented under the agent that made them, so you can see exactly what was called and in what order.

→ Complete Run Log guide

Breakpoint debugging for code

Inside Code nodes and the code editor, set breakpoints to pause execution for Python, JavaScript and TypeScript:

  • Step over, into, and out of lines.
  • Inspect variables and their values while paused.
  • Resume when you're ready.

This runs locally — no server required.

A TypeScript step pauses on the lines you wrote: its types are blanked out where they stand rather than deleted, so nothing shifts up and a breakpoint beside line 15 stops on line 15.

Go, Rust, C, C++ and Zig steps don't have breakpoints. They're compiled before they run, and stepping through a compiled step isn't something Circuitry can offer yet. Print instead — fmt.Println in Go, println! in Rust, printf in C and C++, std.debug.print in Zig — and the output appears in the step's log alongside everything else.

Run from a point

Re-run just part of a workflow: run a single node on its own, or run from a chosen node onward, so you don't repeat expensive earlier steps while iterating.

Tips

  • Inspect a node's output before assuming the next node is at fault — most bugs are upstream.
  • Use breakpoints to check a value mid-computation rather than adding print statements.
  • Re-run from the failing node to iterate quickly.