Run Log

The Run Log is Circuitry's in-app execution trace — a chronological, call-stack-ordered record of every node that ran, how long it took, which model or server it used, and what it returned. It's the first place to look when a workflow does something unexpected.

Opening the Run Log

• Menu → Debug → Show Run Log, or
• click the Run Log toggle button in the top toolbar (the log/list icon near the right).

It opens as a panel beside the canvas. It stays in sync with the active workflow tab — switch tabs and you see that workflow's log.

What each row shows

Every executed node appends a row with:

• Node name + type — e.g. agent AI Agent, mcp Context7, code Transform.
• Timing — wall-clock duration for that node. The Total at the bottom is the whole run.
• Model — a badge (e.g. GPT-4O-MINI) when the node called an LLM.
• Ran on — when a node executed off-device (an EServer), the server name is shown.
• Outcome — success, error (red, with the message), or skipped.

Click any row to expand it and see the node's output in a tree view — the actual data that node produced, including tool-call results.

Call-stack ordering

The log reads top-down as a call stack, not just a flat event list. When an agent calls tools (MCP servers, vector stores, procedures), those calls are indented under the agent that made them:

start   start                         0.0s
agent   AI Agent                            ← the agent starts
  mcp   Context7                      0.6s  ← connects, lists tools
  mcp   Context7 · resolve-library-id 1.0s  ← a tool call
  mcp   Context7 · query-docs         1.8s  ← a tool call
  store Product FAQ · search_…        0.3s  ← a vector-store search
agent   AI Agent                      14s   ← the agent's final answer
Total                                 15s

This makes it obvious which agent invoked which tool, and in what order — the same way a debugger shows nested calls. Procedure (sub-flow) calls nest the same way.

Tracking tool calls

• MCP tool calls appear as indented mcp rows tagged with the server and the tool name (Context7 · query-docs). The edge between the MCP node and the agent also animates while a call is in flight.
• Vector-store searches appear as indented store rows tagged with the store name.
• Connection lifecycle for MCP servers (connecting / ready / error) shows up too, so you can see whether a slow run was the connection or the model.

If a tool call errors or times out, the row turns red with the error message — so a hung MCP server or a bad tool argument is visible immediately rather than silently swallowed.

Loop iterations & fork branches

• Loop nodes increment a per-node run count; each iteration appends its own row, so you can see how many times a node ran and the timing of each pass.
• Fork branches are nested by depth, mirroring the parallel structure on the canvas.

Exporting

The Save log as CSV button (download icon in the Run Log header) exports the run as a spreadsheet: name, type, timing, model, and server columns. Node output is deliberately excluded from the CSV (it can be large and may contain sensitive data) — output stays viewable inline by clicking a row.

Resetting

The ↺ Reset workflow execution state button (in the run controls toolbar) clears node statuses and the current run's state. The Run Log itself accumulates rows across re-runs so you can compare — each re-run appends rather than replacing, with run-count suffixes keeping rows distinct.

When to reach for it

• "My agent didn't use the tool I wired in." Check whether an mcp / store row appears under the agent. No row = the tool wasn't called (often a prompt-phrasing issue — see the MCP and Vector Store guides).
• "The run hung." The last row tells you which node was executing. A red timeout row points at the culprit (commonly an unreachable MCP server).
• "Which model actually ran?" The model badge on the agent row — useful when a node's stored model differs from the picker default.
• "How slow is each step?" Per-row timing + Total isolate the bottleneck.