Reading Execution Logs & Terminating Runs
Every workflow run leaves a detailed execution log — the audit trail for what happened, step by step. It's the place you go to understand a run: what it did, what it cost, and, when something went wrong, exactly where.
Getting there
Open a workspace's execution history (on the manage page) and pick a run to open its log. History is per-workspace — it reflects the active workspace's branch, not the entity as a whole. And because core workspaces are never deleted, execution history is always preserved: even a run whose workspace was later soft-deleted by the plugin remains fully viewable for audit.
What the log shows
The page has two halves:
- a timeline of the run, node by node, in order;
- the configuration snapshots that were in effect — historical carbon copies, so this view never changes when you edit configuration later.
Each timeline node is one of three kinds. Agent nodes show the agent, model, token counts, duration, calculated cost, and the full request and response. Service nodes show the service, usage, duration, cost, and full request/response. Internal nodes are computational steps. If a run failed, the page highlights which node failed and the error. You also see the cumulative cost for the whole run and the per-node cost for each step — all derived from the log itself, which is the financial source of truth during execution.
Terminating a run
From the execution detail page you can terminate a run that's queued or running (the button is hidden for finished runs):
- For a running execution, the platform attempts to stop it on the engine before marking it terminal, so it needs the run's external execution ID — if one isn't stored yet, you'll be asked to provide it.
- For a queued execution, it's marked terminated directly with a log entry; no engine stop is attempted, since it may not have started on the engine yet.
Either way the run ends as failed_transient — an operator decision counts as an external, retryable outcome, not a platform fault.