Module · Executions & debugging
The executions panel
Lesson 6 of 11 · 4 min
The logs panel answers “what just happened”. It is about the run in front of you, and it is gone when you move on.
The Executions tab answers the harder questions. When did this start failing? Does it fail for everyone or only for records with no phone number? Was it working on Tuesday? Every run this workflow has ever done — tests and production alike — is kept here, and that history is the difference between guessing and knowing.
What you are looking at
A list of runs down one side, a tree of the selected run in the middle, and the detail of whichever node you click on the right. Each run in the list carries three things: when it ran, whether it completed, and how long it took.
Duration is the column people ignore and then need. A workflow that normally takes 200 milliseconds and has been taking nine seconds since Thursday is telling you something — usually that an external call is struggling — long before anyone reports a failure. Scanning the column is a five-second health check.
Selecting a run and opening a node gives you the same five views you get while testing: what went in, what came out, a readable preview, the raw structure, and an AI-assisted read of it. The last of those is the next lesson.
Using it as a record rather than a log
Three questions this panel answers that nothing else does:
| Question | How the history answers it |
|---|---|
- How the history answers it
- How the history answers it
- How the history answers it
A past run can be loaded back onto the canvas. That puts a specific historic execution's data in front of you on the workflow itself, which is far easier to reason about than a list — and it is the setup for the next lesson, where you fix a node and re-run from that point using the same upstream data.
What breaks
The history is per workflow, not per organisation. This tab shows this workflow's runs. When a problem crosses two workflows — one triggers another, or both write to the same record — you are reading two histories and matching them by timestamp. Worth knowing before you conclude that something did not happen.
Selecting a run does not change the address of the page. You cannot paste a link to a specific execution for a colleague to open. Sharing means a screenshot or an execution identifier and an instruction to find it — mildly annoying, and worth knowing before you promise somebody a link.
Successful runs are the ones worth reading. Everything this course has warned about produces a completed run: the empty send, the silent truncation, the reply with angle brackets in it, the search that answered a different question. Filtering this list to failures will show you an empty list on a workflow that has been quietly wrong for a month. Read a few green ones.
It is a record of what happened, not of what changed. It does not tell you that somebody edited the workflow on Tuesday, and a run from before an edit shows the old behaviour with no marker saying so. When history stops making sense, ask who changed what — the panel cannot.
Try it
- Open a workflow you have run more than once and read the list. Note the spread of durations before you look at anything else.
- Open the oldest run and the newest and compare the same node in both. If the workflow changed in between, the difference is visible here and nowhere else.
- Find a run that completed and produced a wrong result, and work out from the record alone which node introduced it.
- Load a past run onto the canvas and look at the workflow with that run's data in place. That view is the one worth remembering.
- Then deliberately do not fire the trigger, and confirm no new execution appears. Absence of a run is a diagnosis in itself.
Next: Run and Run From Here — fixing one node and testing the fix without paying for the whole pipeline again.