The install base is split into a growing canary cohort running the new build and a shrinking stable cohort still on the old one, moving through fixed rollout stages: 1% → 5% → 25% → 100%. Each simulated day both cohorts throw crashes at a Poisson rate scaled by their population; the monitor tracks an exponentially-smoothed crash rate per cohort and compares canary against the stable baseline.
canary_rate = baseline_rate × severity
halt when canary_rate_observed > threshold × stable_rate_observed
AND canary population ≥ min sample (500)
AND condition sustained
on halt → rollback: canary% → 0, rollout marked failed
on healthy for dwell_time → advance to next stage
- Regression severity — how much worse the new build's true crash rate is than the old one; 1x means the release is actually safe.
- Halt threshold — how many times the baseline rate the monitor tolerates before it auto-halts; low values catch regressions faster but risk false alarms from noise.
- Install base — total devices; a small install base means the 1% and 5% stages carry too few canary users for the monitor to trust its own numbers ("insufficient sample").
- Stage dwell time — how long a stage must stay healthy before the rollout auto-advances to the next percentage.
Real-world relevance: this is the same staged-rollout / canary-analysis loop that Google Play, the App Store's phased release, and internal deployment systems (Spinnaker, Argo Rollouts) run automatically — catching a bad build after a few thousand users instead of after everyone has it.