An execution is the smallest unit of work in Tines 3B: one run of a single step's code. Every time a step does something, whether as part of a workflow, a scheduled job, or a quick test, that's an execution. Understanding executions helps you read what actually happened when a workflow ran, down to the individual step.
One step, run once
When a step executes, Tines 3B builds that step into a container and runs its command in an isolated sandbox. That single occurrence is an execution. It has a beginning and an end, takes some input, produces some output, and finishes with a result. If the same step runs three times, that's three executions, each its own record.
Read about containerized execution here.
Executions and runs
A run and an execution are related but not the same, and the difference matters. A run is one pass through a whole workflow. An execution is one step within it. As a run moves from step to step, each step it reaches produces an execution, so a run is really a collection of executions tied together by the workflow's structure. When you look at a run, you're looking at the executions that made it up.
Learn more about runs here.
The reverse is true too: an execution always belongs to something larger. A workflow step's execution is part of a run, but executions also happen outside of runs entirely, which is where their variety comes from.
Where executions come from
Not every execution is a workflow step. The same underlying unit powers several different situations:
A workflow step, as part of a run, whether triggered on a schedule, by a request, or manually.
A quick execution in chat, when Tines 3B runs code to test an idea or answer a question.
A connection test, when Tines 3B checks that a connector's credentials work.
They're all executions, which is why the platform can build, run, isolate, and meter them the same way no matter what prompted them.
Build and run
Under the hood, an execution often comes in two phases. A build prepares the step's container image from its Dockerfile, and a run executes the step's command inside it.
The build is skipped when nothing has changed and the image is already cached, so a step you run repeatedly usually goes straight to running. Splitting the two is what lets Tines 3B do the slow setup once and keep later executions fast.
What an execution carries
Each execution is a small, self-contained record of what happened:
Its input, the data it received on standard input.
Its output, what it wrote to standard output, which becomes the input to the next step.
Its log, what it wrote to standard error, kept separate from the data.
Its status, which moves from pending to either success or error.
Its timing, including how long it waited and how long it ran.
Together these let you see not just whether a step worked, but what went in, what came out, and how long it took.
Retries and history
When an execution fails, it can be retried, and the retry is a new execution linked to the one before it, so the trail of attempts stays visible rather than overwriting itself.
Executions are also kept in a workflow's history according to its retention settings, which is what fills the step-by-step views: the run timeline, a step's recent executions, and the logs you inspect when something goes wrong. An execution is fleeting to run but lasting as a record.