Reliability

What happens to a run when something goes wrong that has nothing to do with your code — a transient failure, an orchestrator restarting, a host dying underneath a pinned VM.

A transient failure retries automatically

A run that fails for a transient reason is parked as RETRYING, not FAILED. It is submitted again after a short backoff, up to your tier's attempt budget.

A deliberate refusal still fails at once. If your task declared a network policy the host cannot enforce, a retry would repeat a run the platform already refused.

An orchestrator crash re-queues your run

If the process that dispatches your run crashes, the run is re-queued at the next startup. The number of attempts is capped, so a run that keeps crashing the dispatcher cannot loop for ever.

A planned restart, such as a routine deploy, costs nothing from that budget. The run is marked failed cleanly, because the platform chose to stop.

A pinned VM has one exception

A pinned VM survives idle time and every routine reaper sweep. It does not survive a host restart.

vm:list --pinned then reports the pin as lost. The next run against that task cold-boots a fresh VM, and the pin is set again on it.