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. 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 — 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.
• Replay — the graph drawn as the run walked it.

The timeline 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.

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 the Run control on the canvas. 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. A cancel lets the engine stop cleanly, which is what you want for anything mid-write. A terminate is the blunt instrument for a run that is stuck.

Retry versus resume: a retry starts the work again; a resume picks up from the failed step. 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 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 with the payload it carried so you can replay it.

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.