Lifecycle
Every Run progresses through a small set of states, from the moment it is queued until it reaches a terminal outcome. This page covers the state diagram, how Promote differs from the other operations, how per-container progress relates to the Run-level state, and where logs live.
State diagram
Every Run follows the same general lifecycle: an active phase (Queued, Running) followed by a terminal outcome (Success, Failure, or Aborted). Promote is the exception. It transitions directly to Running, skipping Queued.
Applies to Sync, Profile, Scan, External Scan, Export, and Materialize.
flowchart LR
Queued -->|worker picks up the Run| Running
Queued -.->|user clicks Abort| Aborted
Running -->|all containers processed| Success
Running -.->|unrecoverable error| Failure
Running -.->|user clicks Abort| Aborted
Promote skips Queued and starts directly in Running.
flowchart LR
Running -->|all entities processed| Success
Running -.->|unrecoverable error| Failure
Running -.->|user clicks Abort| Aborted
Solid arrows: automatic transitions. Dotted arrows: user-initiated or error.
Warning indicator
The Warning indicator is not a distinct status. A Run that ends in Success may show a icon next to its ID when the worker recorded log entries during execution. The underlying status remains Success, and the Run is treated as a terminal Success everywhere downstream. See the States at a glance table.
A Run cannot move out of a terminal outcome, but it can be re-launched with Resume or Rerun (see Available Actions). Each of those creates a brand-new Run rather than reopening the original.
Active vs terminal states
| Phase | States | Action that drives the transition |
|---|---|---|
| Active | Queued, Running | Worker progress, unrecoverable error, or user Abort |
| Terminal | Success, Failure, Aborted | User clicks Resume or Rerun (creates a new Run) |
Per-container progress vs Run-level state
Some operations (notably Profile and Scan) track progress at two layers:
- Run-level state. The badge on the Activity row and the terminal outcome for the whole operation.
- Container-level state. The per-container result inside the expanded Run, with its own Success/Failure badge.
These layers are independent. A container can land on Failure while the overall Run still finishes on Success. The failed container is recorded in the per-container Results tab, and the Run-level Success carries the Warning indicator next to the Run ID. The container-level badge uses the same component and palette as the Run-level badge.
For Sync, External Scan, Export, Materialize, and Promote, all the work folds into a single Run-level state. There is no separate per-container badge.
Where logs live
Two log scopes are exposed for every Run:
- Run-level log. Surfaced in the expanded Run's Logs block and on the operation detail page. Captures setup, scheduling, worker-level events, and any unrecoverable error.
- Container-level log. Surfaced alongside each container row inside the expanded Run, when the operation has a per-container progress layer (Profile, Scan). Captures the per-container query and any error that prevented the container from finishing.
Logs stream incrementally while a Run is in Queued or Running. Once the Run reaches a terminal state, the log is frozen.
See also
- Introduction. The purpose of Runs and the building blocks every state exposes.
- Available Actions. Abort, Resume, Rerun, and Delete: when each one is shown and what it does.
- For per-operation walkthroughs with screenshots and per-block tables, see the By Operation Type section on the Runs overview.