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 clusters that 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 (and if you also ship on the App Store, she watches your phased releases and App Review the same way). The ladder, the vitals checks and the halt call stay yours - just never forgotten.