Every time a workflow runs, Sim writes down exactly what happened: the trigger, every block in the order it ran, and for each block its input, its output, its timing, and any error. That record is a log — the ground truth for understanding and debugging a run.
What you will learn
Every run is recorded
You never turn logging on. Each run automatically writes a complete record: the trigger, every block in order, and what each one received, returned, and how long it took.
The log is the ground truth
To see what a run actually did — not what you think it did — you read its log: which blocks ran, in what order, and the real input and output of each.
Debug by reading backwards
Start from the wrong value and trace it back, block by block — which block produced it, what that block read — until you reach the source.
Every run leaves a record
When a workflow runs, the run isn't a black box. Sim records the trigger that started it, every block in the order it executed, and for each block its input, its output, its timing, and an error message if it failed. Nothing about a run is a mystery — it all gets written down.
Here's the kind of workflow whose runs you'll read — a trigger, an agent, and the branches it routes between:
The record
Open a run and the log lists every block in the order it ran, each with its duration. So when a run is slow, you can see exactly where the time went — which block took the seconds — instead of guessing.
What each block did
Selecting a block shows everything it actually did: the input it received, the output it returned, and — for an agent — the tool calls it made and the tokens it used. From the outside a step can look instant; the log keeps everything that happened inside it.
Read it backwards
The log also shows where every value came from. A block's input names the block that produced it — a connection tag like <triage.content>. So to debug, you start from the wrong value and step backwards: which block produced it, what that block read, and on back through the chain until you reach the source. Debugging a workflow is reading its log backward from the symptom.
Every run writes one
You don't enable any of this — every run produces a log automatically. When a workflow does something you didn't expect, the log is the first place to look, because it's the one place that records what actually happened.