Run lifecycle

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 error is in the red banner on Logs.
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

1. Open the run (or find its card under active runs on Latest runs).
2. Press Stop. The pill becomes Stopping…; the button stays visible but disabled with the tooltip Stopping… until the workers confirm.
3. 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. 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.

1. 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.
2. 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.
3. 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.

Delete

Delete run sits in the menu beside the last action on a settled run’s head (or as Actions on a failed run). It removes the run, its logs, 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? This permanently removes the runs and their logs. 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), Needs attention (red for a failure), Last run cancelled (amber).
Pipeline hero	Running pill while a run from this page is in flight; last ran in red after a failure.
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.

What’s next