Run History and Debugging in Workflow Chain Engine
What Every Run Records
The run history page lists every execution with its workflow, trigger type, status, duration, and step count, and each entry opens into the full detail: the ordered step log, and every variable's final value. The runHistory config setting controls how many records to keep, 500 by default, with older runs pruned automatically so the history stays useful without maintenance.
What Each Node Logs
| Node | Its log line tells you |
|---|---|
| HTTP Request | The resolved URL it called, the response status, and a response excerpt, so you see exactly what the API said. |
| If Condition | The comparison it made with both sides resolved, and which way it went. |
| Switch | The value it matched and the case it chose. |
| Set Variable | The variable and the resolved value it assigned. |
| For Each Loop | How many items it walked. |
| Success and Fail End | The final status and the resolved message. |
The pattern across all six: values are logged after placeholder resolution, so the log shows what actually happened, the real URL with the real order ID in it, the real comparison with the real number. Combined with the final variable values, a run detail answers the two questions debugging always asks, what did each step do, and what state did the flow end in.
The Debugging Routine
When a flow misbehaves, the routine is three reads long.
Read the last step first. The log's final line names how the run ended: a Fail message, a stopped run with the error that stopped it, or a Success that returned something unexpected. That line usually points directly at the node to inspect.
Read the branches. Condition and Switch lines show the resolved comparison, so a flow that took the wrong path displays the exact value that steered it. The classic discovery is a value that arrived formatted differently than expected, "42.00" where the flow assumed "42", visible instantly in the logged comparison.
Read the captures. The HTTP node's response excerpt shows what the API really returned, and the final variables show what capture stored. Between the two, every "the variable is empty" mystery resolves in seconds, the excerpt reveals the response's actual shape, and adjusting a capture from first-match to an exact path like {data.total} is the usual fix, the capture guide covers the syntax.
Then reproduce on your terms: Run Now with the same values re-runs the flow from an input box, and the new entry sits next to the old one for comparison. Adjust the node, run, read, a few seconds per cycle.
Reading a Stopped Run
A run that reaches the step budget stops itself with a clear error naming the problem, and its log is the diagnosis: the repeating sequence of steps is right there, showing which nodes cycled and what the loop's condition kept deciding. Wired-back loops that need more headroom get it in one config line, maxSteps, and genuinely runaway logic shows its shape in the repetition. Connection-level HTTP failures stop a run the same way, with the failing node and error logged, while HTTP error statuses like 404 keep the run going for your flow to handle, so each kind of problem surfaces exactly where it belongs.
The History as an Operations Log
Beyond debugging, the history is the flow's paper trail. Each entry names its trigger, so a lead intake workflow shows which runs came from the webhook, the API, or a manual Run Now. Durations expose the slow API in a chain. Fail messages written thoughtfully, "Order 991 had no shipping address", turn the history page into a report a teammate can act on without opening the editor. A scheduled flow's entries confirm at a glance that the cron runner is doing its rounds, every minute accounted for.
Every run stores a readable step log, resolved values included, plus every variable's final state. Debug by reading the last step, then the branches, then the captures, and reproduce with Run Now. Write descriptive Fail messages and the history doubles as an operations report.