Sign inStart creating

Resuming an interrupted run

Long runs survive crashes. Resuming runs only what is missing and never re-bills completed work.

Open it →

Studio → a project → Runs.

A feature is thousands of chained jobs over hours. Crashes, deploys and provider outages are certainties rather than edge cases.

### The rule

Nothing already paid for is ever regenerated.

Everything follows from that. Progress is recorded per unit, so an interruption at shot 47 of 60 loses at most one shot. Resuming diffs what the project needs against what already exists and runs only the gap.

The Resume button says "already complete: 47/60" rather than just "Resume", because if you cannot tell whether your work survived, the rational thing to do is start over — which is the expensive option.

### The diff is live

The desired unit list is recomputed on every resume from the current project, not from a snapshot taken when the run started. Add three shots overnight and they are included; delete one and it is not regenerated into a project that no longer wants it.

### Workers that die

Units are claimed with a lease rather than a lock. A worker that crashes never releases a lock, and the unit is stranded until someone opens a database console — which is the failure this is meant to survive. A lease simply expires and the next pass picks the unit up.

### Resume count

A run that has restarted nine times is failing, not merely slow. The count is shown for exactly that reason.

### Cancelling

Completed work is kept. Cancelling stops the outstanding units; it does not throw away what was already generated and paid for.

Did this answer your question?

Related

All help articlesAsk the community