Spot Runners & Savings

Spot runners use spare cloud capacity at a lower price, but the provider can reclaim them. Request spot with a packed runner label:

runs-on: machine/gpu=l4/tenancy=spot

Choose your team’s placement strategy and recovery settings in Settings → General. Only team admins can change these settings. For work that cannot tolerate interruption, request tenancy=on_demand.

Placement strategy

Intelligent Tiering Strategy ranks the available spot options within your allowed regions:

Balanced can favor a slightly more expensive zone when the cheapest zone has a worse reclamation record. The risk signal is historical and cannot guarantee uninterrupted execution. All strategies respect your regions= restriction and prefer eligible spot options ahead of an on-demand fallback.

These are team settings, not extra runs-on selectors. See Regions & availability for location restrictions.

On-demand fallback

On-Demand Fallback controls what happens when a spot request exhausts spot capacity:

• Enable fallback to allow an on-demand runner instead.
• Disable fallback to keep the request spot-only; it can fail if spot capacity cannot be obtained.

Fallback can increase the compute rate. If your workflow needs a strict spot-only budget, disable it. Check the pricing page for current spot and on-demand rates.

Interruption retry

Spot Interruption Retry controls a separate case: a spot runner is reclaimed before it starts the job. With Retry on on-demand selected and On-Demand Fallback enabled, machine.dev re-provisions that waiting job onto on-demand. The retry joins the back of the team’s admission queue and still needs sufficient balance and an available concurrency slot.

Do not retry leaves that recovery disabled. Interruption retry has no effect when on-demand fallback is disabled.

Jobs already running

machine.dev does not automatically re-run or resume a job interrupted after it started. Save checkpoints to durable storage and re-run the workflow with resume logic. See Cost optimization.

Spot & Savings

Select Spot in the dashboard sidebar to open Spot & Savings and select a date range. The page shows savings against on-demand, spot share and interruption information, with a breakdown by runner, region, availability zone, or tenancy. A savings card also appears on the main dashboard.

How savings are calculated

When a runner launches, machine.dev records the on-demand compute rate for the same configuration and region. The comparison uses your billed runtime, substitutes that on-demand compute rate, and keeps storage costs unchanged. On-demand jobs contribute zero savings. This estimates the cost of running the same work entirely on-demand; it does not estimate how much time was lost to failed work.

Historical jobs without a recorded on-demand baseline count at actual cost with zero measured savings. Historical baselines are not invented or backfilled, so periods containing those jobs can understate savings.

How interruptions are counted

The page distinguishes interrupted jobs from runners reclaimed before starting a job. A pre-start reclamation has no running job to count, even when it results in a successful on-demand retry. Confirmed spot reclamations are distinguished from unrelated host failures and manual termination.

Jobs interrupted while running are labelled interrupted in the Jobs table and job details, with the recorded on-demand comparison and savings where available. Billing stops at interruption. Use these observations alongside the provider’s historical interruption information on the pricing page when deciding whether to change strategy.

Next steps

• Cost optimization: checkpointing and right-sizing
• Spend analysis: costs by workflow, branch and commit
• Billing & limits: concurrency, runtime and automatic top-ups