Run lifecycle
Every state a run passes through, including stopping and looks stuck, why runs are cancelled, and how Stop, Resume and Delete work.
A run moves through a small number of states, and each one shows up the same way everywhere: on the run head, in the runs rail, on cards and on the Latest runs page. Knowing the states makes the rest of the product easy to read.
States
| State | Pill | What is happening |
|---|---|---|
| Queued | Queued (orange head) | The run exists and is waiting for a worker. Waiting for an available runner. This run will start automatically. |
| Running | Running / Running — <step> (brand head, pulsing) |
Workers are executing the steps. The head names the current step when known. |
| Stopping | Stopping… (slate head) | A stop was requested. Winding down — the run is being stopped and will finish shortly. In-flight fetches finish or are abandoned, then the run becomes cancelled. |
| Completed | Completed (green head) | Every step finished and the checks passed. A live run has published; a test or debug run has kept its rows privately. |
| Failed | Failed (red head) | A step raised an error, or the end-of-run checks turned the run into a failure (for example no rows). The Summary names the step it failed in, and that step’s Details panel in Steps shows the error. A failed live run also makes the pipeline degraded. |
| Cancelled | Cancelled (slate head) | The run stopped before finishing. The detail line says why. |
Active means queued, running or stopping. Only active runs can be stopped; only settled runs (completed, failed, cancelled) can be deleted.
Looks stuck
An active run that has recorded no activity for 30 minutes is flagged Looks stuck with an amber head: No activity for 34 minutes during extract_offers. You can stop the run, or ask Jason to investigate. The run is not cancelled; it may be waiting on a slow source. Ask Jason replaces Fix with Jason in the actions, and Stop is available. If a run is genuinely lost, the platform’s own watchdog cancels it and the detail line records it.
Why a run is cancelled
The detail line under a Cancelled pill names the cause; the run’s Summary repeats it in its sentence.
| Detail line | Cause |
|---|---|
| Stopped by Maya Okafor. | A person pressed Stop on the run page or on Latest runs. |
| Stopped by a user. | Stopped by a person whose name is not recorded. |
| The worker processing this run was lost. | The worker executing the run went away (for example during maintenance) before it could hand the run over. |
| Stopped by the stall watchdog. | The platform cancelled a run that stopped reporting activity. |
| Stopped after hitting its time limit. | The run exceeded the maximum duration allowed for a single run. |
| Stopped externally. | Stopped by something other than the above. |
A reason may follow the line after a dash when one was given.
A cancelled live run does not publish. Its partial rows stay on its Outputs tab, marked not published, and the dataset keeps its last published revision.
Stop
- Open the run (or find its card under active runs on Latest runs).
- Press Stop. The pill becomes Stopping…; the button stays visible but disabled with the tooltip Stopping… until the workers confirm.
- Read the result. The run becomes Cancelled with Stopped by your name. Anyone who asked to be notified when the run finishes is notified now, and any alert rule on run status fires.
Stopping does not affect the schedule: the next slot fires as usual. A cancelled run does not make the pipeline degraded; only a failure does. Stopping does not roll anything back either; the dataset is untouched because nothing was published.
Resuming
A failed or cancelled run whose workers had completed at least one stage offers Resume in the head. Resuming reuses the rows that stage produced and reruns everything after it, as a new run.
- Press Resume on the failed or cancelled run. The dialog Resume run? reads Jsonify will reuse 1,240 rows from fetch_catalogue and rerun every downstream stage., lists Reused boundary fetch_catalogue and Pipeline version v2, and notes This creates a new run. The failed run stays unchanged.
- Start resumed run. A new run appears in the rail as a Resumed run, numbered like any live run. Its Summary shows Recovery · Reused stage fetch_catalogue from run #7.
- Let it finish. The resumed run publishes when its checks pass, exactly like a live run.
The resumed run uses the pipeline version recorded on the dialog. When a repair has activated a newer version in the meantime, that newer version is what runs after the reused stage, which is how a repaired pipeline finishes the work a failed run started without re-fetching what already succeeded.
A run failed at the third of five steps after fetching 2,400 product pages. Resume reuses those 2,400 pages’ rows and reruns the last three steps in a few minutes instead of an hour.
Runs with no completed stage do not offer Resume; start a new run instead.
Degraded after a failure
When a pipeline’s latest live run fails, the pipeline is degraded until a repair lands and a live run succeeds again. This applies whoever started the failed run: the schedule, a trigger, you or Jason.
The failed run itself stays failed. Resume is still offered on it when a stage completed, and is the quickest way to finish its work once a repair has activated a new version. How healing starts, and Autoheal now, are covered in Verification and repair.
Delete
Delete run sits in the menu on the arrow beside the last action on a settled run’s head, or is a red button of its own when there is no other action. It removes the run, its activity, its fetched pages and its output rows. Datasets the run published keep their revisions. There is no confirmation on the run page; you land on the neighbouring run afterwards, or on the Runs tab if none is left.
To delete several at once, use the checkboxes on Latest runs, which does confirm: Delete 4 runs?, with a warning that the runs are removed permanently and the datasets they produced are not affected.
Deleting a run removes the provenance behind the rows it published. The rows stay in the dataset, but Origin on a row can no longer show the fetch and screenshot that produced it. Keep runs whose rows you may need to audit.
Where states show up
| Surface | How a state appears |
|---|---|
| Run head | Pill, background tint, detail line. |
| Runs rail | Status icon on each row; live rows tick their elapsed time; active runs sit under Active. |
| Pipeline card and Home | Queued / Running / Stopping (blue), Finished successfully (emerald), Last run cancelled (amber). After a failed live run, the degraded sentence and an alert icon. |
| Pipeline hero | Running pill while a run from this page is in flight; one banner per active run; last ran in red after a failure, and the degraded banner under the hero. |
| Latest runs | Status filter; cards for active runs with Stop; status text on previous runs. |
| Home › Needs attention | A pipeline whose latest run failed, with Failure 2 hours ago · Last run failed. |