The traditional patch schedule is a calendar: dev on the first weekend, test on the second, production on the third. It feels rigorous. It is actually a slow-motion version of patching everything at once, because nothing in the schedule asks whether the earlier waves went well before the later ones fire.
Rings are waves plus a question
A ring-based rollout deploys to a small canary population first — but the defining feature is the promotion gate: the rollout only proceeds when the canary population’s health, measured against its own pre-patch baseline, stays within budget. The question "did anything get worse?" is asked by telemetry, not by waiting a week and assuming silence means success.
Health means boring, observable signals: service availability, crash counts, boot time, helpdesk ticket rate tagged to the ring population. A regression in any of them past the threshold halts promotion automatically.
The maths that sells it
Assume a bad patch that breaks 1 in 20 monthly cycles. Calendar waves put it on every production machine by week three, and you find out from the flood. Rings with a 1% canary and health gates find it while it affects 1% — and because promotion is automatic when health is green, the good patches (19 in 20) actually reach production faster than the calendar did. Lower risk and higher velocity is a rare trade; rings genuinely deliver both.
Our standard ring structure: 1% canary (volunteer power users and IT’s own machines), 10% pilot spread across departments and hardware classes, 40% broad, then the remainder including change-sensitive systems. Emergency patches use the same rings with compressed dwell times — 24 hours instead of a week — rather than skipping the structure.