Execution Log

The Execution Log answers: What happened in this workflow’s run, Step by Step? Open it on the canvas to see which Steps ran, what each one produced and where the run stopped.

Use Activity to monitor runs and alerts across the workspace. Use a Step’s Executions tab after the log has shown you which Step needs closer inspection.

Opening it

The Execution Log is the notebook icon in the toolbar above the canvas, to the right of undo, redo and the workflow-data controls. It opens over the canvas and closes with the X in its corner.

Before a workflow has run, it says so: “This workflow hasn’t run yet. Run it to see each step’s activity here.” Press Run and the log fills as the workflow goes.

Reading a run

Runs are grouped newest first, each with a heading summarising it:

Latest run · 1 step · All steps succeeded          18:18:36

The heading gives you three things at a glance: which run it is, how many steps it covered, and how it ended. Click it to collapse or expand that run.

Older runs are labelled by how far back they are: Previous run, then 2 runs ago and so on, with anything further back under Earlier activity. A run still going says Running… until it settles.

Each step appears when it starts, and again when it finishes

Inside a run, entries are events rather than a list of steps:

So a step that ran normally shows twice, once as Running and once as Completed. The two timestamps tell you how long it took. In the run above, the Code editor step started at 18:18:36 and completed at 18:18:42, so it took six seconds.

The result sits under the step

A completed step shows what it produced, so you can check the shape of the data without leaving the log:

{"result":{"text":"…","success":true,"executableCode":"…","executionOutput":"Total with VAT: 121.00\n", …

Each entry carries the step’s number and name, and clicking it opens that step on the canvas. That is the quickest way to get from “this is wrong” to fixing it.

Finding one thing in a long run

The Search box at the top filters the log to matching events. Useful for a workflow with many steps, or for finding every time one step ran across several runs. When nothing matches, it tells you: “No events match your search.”

Searching reaches into runs that are collapsed, so a match in an older run opens that run to show you.

What to do with a failed run

Start at the bottom of the failed run. The last entry before it stopped is the step that failed, and its message says why.

From there:

• The step failed on data it did not expect. Open it from the log and check the result of the step before it: the shape may not be what the step assumed.

• The step failed on an external service. Turn on Retry on fail for it, under Test & Debug. Retries are off until you turn them on. See Error Handling & Retries.

• The message matches none of these. Look it up in Troubleshooting & Errors, which covers the common failures grouped by symptom.

How long the log keeps things

Run records are kept for 30 days after the run finishes, and each step’s results on its Executions tab follow the same clock. The log states the window itself, in a note under its header. Each run keeps the retention policy in effect when it started. A workflow whose older runs have aged out says so in place of the list, so an empty log does not mean the workflow never ran.

That is short on purpose, since the payloads passing through a workflow can contain customer data. It also means the log is for debugging rather than for record-keeping: if you need a lasting trail of what an automation did, write it somewhere durable as part of the workflow — a spreadsheet row, or a record in your own system.

What’s Next?

• 👉 Step-Level Executions →: inspect the affected Step’s input, output and attempts.
• Activity: monitor runs and alerts across the workspace.
• Error Handling & Retries: configure retries and failure routes for future runs.