Overview

A log is the recorded trace of one workflow run. Every time a workflow runs, Sim writes down what triggered it, which blocks ran in what order, and for each block its exact input, its output, and any error. That trace is the ground truth for debugging: it replays what each block received, what it did, and what it returned, so you can find where something went wrong.

Think of it like a video replay of the run, where you read what actually happened one block at a time.

The Logs page lists every run across your workspace, one row per run. The Logging reference covers the page itself: the columns, filters, and sidebar. This page covers what a log captures and how to trace a failure back to its cause.

What a log records

The run

Each row on the Logs page is one run. It records the trigger that started it (manual, api, schedule, chat, webhook, mcp, mothership, copilot, workflow, or a2a), a status, a duration, and the cost in credits. It also carries an execution ID that uniquely names the run.

The status shows the run's outcome at a glance, with failed runs badged Error. When you are hunting a failure, you filter the list to the errors and start there.

The blocks

Open a run and Log Details shows the trace. The Trace tab lists each block as a span with its timing, in the order they ran; each block execution records the block's name and type, its own status, its input, its output, and an error message if it failed.

This is the level you debug at, because a run fails when one of its blocks fails, and a block usually fails because of the input it received. In this run, one glance at the spans shows where the time went: the HealingAgent took 7.83s of the 11.61s total.

Input and output

Each block in the sidebar has two tabs. The Input tab shows the resolved values the block actually ran with: the literal values you typed, and the earlier outputs it read by reference (with API keys redacted). The Output tab shows what the block produced, formatted as an object, with markdown rendered for agent-generated text.

The input tab is the important one. A block reads earlier outputs by name, written <blockName.field>, and the input tab shows what those references resolved to at run time. If a reference pointed at a value that was not there, you see it here as missing or wrong, not as the tag you wrote. See how blocks pass data for how those references resolve.

The same inspector follows you into the editor: during manual and chat runs, the console shows each block's Output and Input live, with values as a typed tree.

The snapshot

A workflow changes over time. A log does not. Clicking View Snapshot opens a frozen copy of the workflow exactly as it was when that run happened: the blocks, the connections, the configuration. This matters when a run failed last week and you have edited the workflow since. The snapshot shows the version that actually ran, not today's version.

Tracing a failure backward

Debugging follows the same repeatable loop each time. You start at the block that failed and walk back to the block that caused it.

1. Find the failed block. Open the errored run. The sidebar marks the block whose status is error. Read its error message.
2. Read its input. Open the block's Input tab. This is what it actually ran with, after every reference resolved.
3. Verify the input. Ask whether that input is what the block expected. An empty field, a value of the wrong type, a missing nested key: the mismatch is usually visible here.
4. Walk back to the source. A bad input came from somewhere. Find the earlier block whose output the failed block referenced, and open that block's Output tab. Either it produced the wrong value, or it never ran.
5. Fix and rerun. Correct the reference, the configuration, or the upstream block, then run the workflow again.
6. Compare the traces. Open the new run's log next to the old one. The block that was error is now success, and its input is the value you expected. That confirms the fix.

Common failures

Most errors come down to a handful of input mismatches. Knowing the shape speeds up step 3.

• Missing input. A field the block needs was left empty, or its reference resolved to nothing.
• Wrong reference. The tag names an output that does not exist, or uses the wrong field name.
• Type mismatch. A string where an object was expected, or the reverse.
• Missing nested key. The referenced object exists, but the specific field inside it does not.
• Empty agent message. An Agent returned nothing, so the next block had nothing to read.
• External error. A tool or API the block called returned an error of its own, surfaced in the block's error message.

When a value is the wrong shape, reshape it in a Function block, whose result becomes its own output that later blocks can read.

AI-assisted debugging

Mothership and Copilot can read a run's logs and propose a fix from the trace: the error message, the input the block received, and the output the upstream block produced. The logs stay the ground truth. You confirm a proposed fix the same way you confirm your own: rerun the workflow and compare the new trace against the failed one.

Retention

Logs are kept so you can debug a run after it happened. Free plans retain logs for 7 days, after which they are archived to cloud storage and removed from the database. Pro, Team, and Enterprise plans retain logs indefinitely.

Next