Runs

Every run is a record you can open in Cockpit under Integration Studio → Runs, or from the workflow itself. It is the only complete account of what an integration actually did, and reading one well is the whole of operating a workflow.

What a run record holds

• Details — how the run ended, when it started and finished, and its result, one block per step that produced output. A failed run carries the platform's own reason. Where the result contains a value under a key that names a URL — a downloadUrl, say — it is offered as a link above the result.
• Timeline — the Steps list, one entry per step in run order, naming the node, how it ended and how long it took; opening a step shows its input and output. Below it, a time chart of what the engine did while the run executed.
• Replay — the graph drawn as the run walked it.

The Steps list is where debugging happens. A step's recorded input is what the node actually received after every expression was resolved, so a path that looked right in the editor and produced nothing is visible here as an empty field — see Expressions.

Steps are recorded per node instance, so an iterator's body shows one entry per element, in the order they ran. Steps that were skipped because a branch ended without delivering are listed too, after the steps that ran, marked as skipped, naming the split step and its port and the branch's position counted from 1 in the order its connections were saved. They appear once the run has completed.

Starting a run by hand

Two levels of test, and you want both while you are building:

• One node at a time, from the node inspector — run this step against a sample input and read its output and logs. This is where a mapping gets fixed. See Node configuration.
• The whole workflow, with Run in the editor header, beside Save, or Run workflow in the canvas's right-click menu. If any node reads from the trigger payload, you are asked for a payload first; otherwise the run starts straight away. The modes offered are the ones the workflow's execution_mode allows — one if it is pinned, both if the caller may choose. A payload that is not valid JSON stops the run and says so.

If you press Run while the bundle is still building, the request is held and starts on its own once the bundle is ready. See Execution modes.

A run started this way is a real run: it appears in the run history, it writes what the workflow tells it to write, and it consumes the same credentials. Test against a system you are allowed to write to.

Acting on a run

The distinction between cancel and terminate is worth respecting, and neither of them is gentle. A cancel signals the running step to abort, gives it a few seconds to clean up and then kills it; because the engine reconciles the outcome afterwards, the run can still read as running for a moment after you ask. A terminate kills the run with no cleanup at all and marks it terminated immediately.

Neither one lets the current step finish. If the step was part-way through writing to an external system, that write is part-way through at the other end too — so treat both as containment, not as a clean stop, and reconcile against the steps afterwards.

Retry versus resume: a retry starts the work again, with the workflow as it is saved now; a resume picks up from the failed step and does not pick up edits you have saved since. Resume is the right choice when the earlier steps did real work you do not want repeated — a file already staged, a batch already accepted — and a retry is right when the whole thing should happen again from the top. Neither is safe on a workflow whose writes are not idempotent, which is the argument for making them idempotent.

Live runs versus history

A run that is in flight and a run that finished are the same record at different moments. The list shows both, and the outcome column is the one to filter on.

Two limits to know:

• Run history is not an archive. The number of runs a page can reach back through is limited today, and there is no retention or export promise. If you need a durable record of what an integration did, write it somewhere you own as part of the workflow — an append to a log file over SFTP, a call to your own service.
• A run belongs to the revision that ran. Restoring an earlier revision does not rewrite the runs the later one produced. See Revisions and audit.

When there is no run at all

A schedule or event trigger that fired while the workflow's build was not ready does not produce a run. Do not go looking for a failed run — look under Missed runs, where the firing is kept so you can replay it (an event keeps its payload, a schedule keeps none). A webhook call in that window is refused with a 409 and kept nowhere, so the caller has to send it again.

Where to go next

• Failure handling — why a step failed and what happened next.
• Missed runs — firings that never became a run.
• Revisions and audit — which version of the workflow this run executed.
• Execution modes — the build gate and the synchronous cap.