Skip to content

Promoting deployments

The default rollout shape in SimpleOTA is manual ramping. You create a deployment at low percentage, watch the metrics, then raise.

A safe default ramp

Step Percentage Wait for
1 5% At least 24h and a healthy success rate.
2 25% At least 24h, no spike in failed reports.
3 50% A few hours, watching for support tickets.
4 100% Done.

Same rollout_seed throughout. The cohort math means buckets that were already exposed at 5% are still exposed at 25%; you only add buckets, never reshuffle.

What to watch

The deployment detail page surfaces, from what devices report to /api/v1/ota/status/:

  • Offered: devices that fell inside the cohort cutoff.
  • Downloaded: reported event: downloaded.
  • Confirmed: reported event: confirmed, the terminal success. The device booted the new image and confirmed it.
  • Failed: reported event: failed. The reason is surfaced too.
  • Rolled back: reported event: rolled_back after a trial install timed out.
  • Pending: offered, with no terminal status yet.

A typical canary failure pattern: Failed > 2% of Offered within the first hour. That's your cue to pause the deployment (it's a button), investigate, and either roll forward (next build) or cut a revert deployment. Cancel is also available at any percentage if you want it stopped rather than held.

Stopping at 100%: when is it "done"?

A deployment with percentage = 100 and pending = 0 is effectively finished, but it stays active until you say otherwise. Click Complete (or POST {"action": "complete"}) when you are satisfied. Completion is deliberate rather than automatic, because only you know whether the stragglers matter.

Completed deployments stay in the audit trail; they just don't participate in the offer-decision query path.

See also