Runs and Debugging

When an automation misbehaves, the automation is rarely where the answer is. The run is. A run records what actually happened, step by step, with the values that were really there rather than the ones you expected.

What a run records

Each execution stores its trigger source, its status, and one entry per step. A step entry carries:

The input field is the one that solves most problems. Templates are resolved by the time a node runs, so the input shows the value that arrived — not the template you wrote. A flow that looks correct and behaves wrongly is nearly always a template that resolved to something other than what you assumed, and this is where you see it.

Statuses

A run, and each of its steps, can be in one of:

Skipped is not failure. A branch that did not run leaves its nodes skipped, and that is usually correct — it is only a problem when you expected that branch to be the one taken. Reading a false-path full of skipped nodes as "broken" sends people debugging the wrong half of the flow.

Trigger source

Every run says how it started: manual, event, webhook, schedule, or another automation calling it.

That answers a specific and common confusion — why did this run at 3am when nobody touched anything? — and it distinguishes a flow you started while testing from one the system started on its own.

Where things actually go wrong

Ranked by how often they turn up:

A template pointed at nothing. Check the step's input. If it shows a literal {{context.steps...}} string, an earlier node did not run, or its key is different from the one you typed.

A skipped branch fed a later node. A template from a bypassed node arrives as text, which is truthy, so || fallbacks do not save you. Fix the branch, not the value.

A comparison against a display name. Status columns come back as option ids. A condition testing for "Approved" never matches.

Nothing was configured to send. Email that never arrives is often a workspace with no mailing provider set up, not a broken node.

Someone else's API failed. Look at the step's error before assuming the flow is at fault. This is what Try/Catch is for.

Habits that make runs readable

Name your steps for what they do. A step called queryCustomers is greppable in the run list and readable in a template. Default names are not.

Leave notes on the canvas. The Note node costs nothing and explains a decision that will not be obvious later.

Wrap external calls in Try/Catch, and write the error somewhere. A caught error that vanishes is only marginally better than a crash — put it in a row or a message so a failure is discoverable without opening the run history.

Test with a manual trigger. Build the flow with a manual trigger, run it until it is right, then switch to the real one. Debugging a schedule by waiting for 3am is a bad way to spend a week.

Secrets stay out of runs

A value read with the Vault node never appears in a step's input, output or logs. That is deliberate, and it means a run is safe to share with a colleague.

The corollary: anything you paste into a plain configuration field does appear. That is the strongest practical reason to use the Vault rather than a config field — not that someone might steal it, but that it will be sitting in run history, in exports, and in the screenshot you send to whoever is helping you.

Next

• Server-side logic — Try/Catch and error handling in depth

• Logic nodes — branching, and why the False path matters

• Automations overview — context and templates, from the start