Executions
The connected runs of more than one task: one piece of work as it moves from member to member.
What an execution is
A run is one pass of one task. When a task hands its result to another task, and that one to the next, those runs are one execution: the whole piece of work, however many members and teams it crosses.
Runs join an execution only through an explicit link: a handoff to a successor, a retry, a recovery, or a resume. Two runs about the same issue, or at the same time, are not joined unless one led to the other. A run on its own, or a task retrying itself without ever handing off, is a run and not an execution: it is on Runs, not Executions.
An execution keeps one address for good: the run it started at. Any of its runs' addresses also opens it.
The board
Executions in the portal is a board of four lanes, which you can search and filter by team or member:
| Lane | What is in it |
|---|---|
| Ready | Queued, about to start. |
| In Progress | Running now. |
| Blocked | Waiting on you (a gate), or paused because a spend cap was reached; or one of its runs is on Blockers, as a failure nobody has cleared, a blocked run, or a pipeline that stopped. |
| Complete | Everything else. Its status still says how it ended: succeeded, failed, cancelled, skipped, or stopped. |
An execution that crosses several teams appears on each of those teams' boards. A failed attempt that a retry then completes does not make the execution fail; a failed or missing handoff stays visible even when another branch finishes. The board and each execution's page update every few seconds while you are looking at them.
One execution
An execution's page shows the task graph it moved through (every successor the tasks are set to hand to, and which ones it took), the run history with each run's member and team, and the current task. Select a task to see its attempts and open any run. Runs' own logs, gates and actions stay on the run's page.
A task can give its execution a name and attach links (the issue, the pull request, the preview) while it runs; they show on the execution and on its runs. Until one does, an execution is named after its first task.
Cancelling and closing
Cancel stops every open run in the execution.
Close takes a finished execution off the board, so the board shows current work. Only an execution in the Complete lane can be closed: anything queued, running, waiting or still on Blockers cannot, so a close never hides work that needs someone. Closing records who and when, changes nothing about the runs, and can be undone with Reopen. If new work joins a closed execution (a retry, a new handoff), it comes back on the board.
Close completed closes every execution in the Complete lane under the current search and team filter, after confirming how many.
Over the API
With an API token scoped executions:read (and executions:write to change them):
| Call | What it does |
|---|---|
GET /v1/executions |
The executions, as a paginated list. Closed ones only with closed=true. |
GET /v1/executions/board |
Every lane in one read, with the same search, team and member filters. |
GET /v1/executions/{id} |
One execution: its runs, links and task graph. Any of its run ids works. |
POST /v1/executions/{id}/cancel |
Stop every open run in it. |
POST /v1/executions/{id}/close, …/reopen |
Take a finished execution off the board, or put it back. A refused close is a 409 that says why. |
POST /v1/executions/close-completed |
Close every execution in the Complete lane under the given filters. |
GET /v1/executions/counts |
How many executions and runs are running, queued and waiting. |
Responses leave out run inputs, logs and results; read those on the run.