Staged rollouts on Google Play: a practical playbook
A staged rollout is the cheapest insurance in mobile development: Google Play lets you ship a release to a percentage of your users, watch what happens, and only then let it reach everyone. Used well, it turns a would-be catastrophe into a footnote. Used badly - or not at all - it turns a bad build into a week of 1-star reviews you can't unsend.
Why bother when your tests pass
Because production is where the weird devices live. Your test matrix does not include the four-year-old tablet on Android 11 with a custom OEM skin and 200MB of free storage, and Play's device catalog spans thousands of configurations you will never see locally. A crash that affects 2% of devices is invisible in testing and very visible in your Android vitals - and vitals affect your ranking.
A sensible percentage ladder
There is no official ladder; the trade-off is speed versus blast radius. A pattern that works for most indie-scale apps:
- 5-10% - the canary step. Big enough to generate crash signal within hours for a mid-sized app, small enough that a bad build touches few users.
- 25% - after a day or two of clean vitals. This is where lower-volume crash clusters become statistically visible.
- 50% - the point of no easy return psychologically; keep the same discipline about checking before advancing.
- 75-99% - a brief final step. Holding at 99% for a short window keeps the halt button available; at 100% the rollout can no longer be halted, only superseded by a new release.
The single most important rule: advancing is a decision, not a schedule. Each step should be gated on what the vitals say, not on the calendar alone.
What to watch at each step
- User-perceived crash rate and ANR rate, compared to your previous release - a regression matters even if you're still under Play's thresholds.
- New crash clustersthat didn't exist in the prior version, even at low volume. New is worse than known.
- Fresh 1-star reviews mentioning the update. Users report breakage faster than dashboards aggregate it.
- Uninstalls and core-flow metrics, if you have analytics on them - a release can be stable and still be a product regression.
Halting: do it early, not gracefully
When the canary step shows a real regression, halt first and investigate second. A halted rollout stops new users from getting the bad build while you diagnose; users who already got it will pick up your fixed release next. The failure mode to avoid is the hopeful wait - "let's see if the crash rate settles" - while the rollout percentage keeps multiplying your exposure.
The honest problem: this is a babysitting job
Everything above amounts to checking dashboards several times a day for a week, per release. It's exactly the kind of vigilance that decays - the first release you ship after reading this will get the full treatment, the tenth will get promoted to 100% on day one because you were busy.
This is where an agent earns its keep - and where Nalya helps today: she watches your releases around the clock and notifies you the moment a rollout's status changes, so the dashboard-checking fragments collapse into a heads-up on your phone. The ladder, the vitals checks and the halt call stay yours - just never forgotten.