Shipping a release to 100% of your users at once is a bet that your testing caught everything. Testing never catches everything. A google play staged rollout lets you release to a small percentage of users first, watch the metrics, and expand — or halt — based on real-world evidence. This guide covers how percentage rollouts work, how to halt a bad one, best practices, crash monitoring, and deciding when to go full production.
How percentage rollouts work
In Play Console, when you create a production release you can choose rollout percentage instead of full rollout. Start at, say, 10%: Google Play serves the new version to a random 10% of eligible devices and keeps the rest on the previous version. Users are assigned deterministically per device, so a user in the rollout cohort stays in it.
Increasing the percentage is a one-click action in Release → Production → Manage rollout: 10% → 50% → 100%. Each increase takes time to propagate as devices check in for updates — expect hours, not minutes, for large user bases. Decreasing the percentage is not possible; you can only halt or continue forward.
Important mechanics to understand:
- Rollout cohorts are sticky. Once a device is offered the new version, it stays eligible for it even if you halt. Halting stops new devices from getting the update; it does not roll anyone back.
- New installs get the latest rollout version. If your rollout is at 20%, roughly 20% of new installers receive the new version.
- versionCode rules still apply. A hotfix during a paused rollout needs a higher versionCode and becomes a new release — you cannot silently patch a halted rollout.
Halting a bad rollout
This is the entire point of staged rollouts. If crash rates spike or support tickets flood in, go to your production release and click Halt rollout. Effects:
- No new devices are offered the bad version.
- Devices that already updated keep the bad version — you must ship a fix.
- Your previous production version remains the "full" version for everyone else.
The recovery playbook:
- Halt immediately. Do not wait for more data when the signal is clear.
- Diagnose from crash reports and vitals (more on monitoring below).
- Build the fix with a higher versionCode.
- Ship the fix as a new staged rollout — start small again, even if the fix feels obvious.
- Only after the fix proves stable, complete the rollout to 100%.
One subtle trap: halting and then shipping the fix at 100% skips the safety net that would have caught the original bug. Resist the urge. The fix deserves its own staged rollout.
Rollout best practices
Match the ramp to the risk. A routine bugfix release can go 20% → 50% → 100% over a day or two. A release with a database migration, a new payments flow, or a major SDK upgrade deserves a slower ramp: 1% → 5% → 20% → 50% → 100%, with at least 24 hours of soak time at the early stages. There is no prize for finishing first; the prize is not shipping a regression to millions.
Bake in soak time, not just percentages. Crash signals need time to accumulate. A 5% rollout held for two hours on a Tuesday morning tells you almost nothing; the same 5% held for 48 hours across varied usage patterns tells you a great deal.
Coordinate with your release train. Do not start a second production rollout while the first is still ramping — overlapping releases make it impossible to attribute a metric change to a specific build. Finish or halt the in-flight rollout first.
Communicate the plan. Support teams should know a rollout is in progress, what changed, and what the halt criteria are. The engineer watching the dashboard at 2 AM should not be deciding alone whether a 0.3% crash-rate increase is acceptable.
Use tracks as pre-stages. Internal → closed → open testing → production staged rollout is a funnel. Each stage filters out a class of problems: internal catches build breakage, closed catches functional bugs with friendly users, open testing catches device diversity issues, and the staged production rollout catches scale effects.
Monitoring crash rates during rollout
Play Console's Android vitals is your primary dashboard during a rollout. Watch these specifically:
- Crash rate (user-perceived): the percentage of daily users experiencing at least one crash. Compare the rollout cohort against your baseline. Google's bad-behavior thresholds (around 1.09% for crashes, 0.47% for ANRs) are useful tripwires, but your own historical baseline matters more — a jump from 0.2% to 0.6% is a halt signal even if it is under Google's threshold.
- ANR rate: application-not-responding errors often spike with main-thread work introduced in a release.
- Cluster breakdown: vitals groups crashes by stack-trace cluster. One new cluster dominating the rollout cohort is the classic smoking gun.
Set explicit halt criteria before the rollout starts, e.g.: "halt if user-perceived crash rate exceeds 2× baseline for 4 consecutive hours, or if any single new crash cluster affects >0.5% of the rollout cohort." Pre-committed criteria prevent 2 AM rationalization.
Complement vitals with your own telemetry (Firebase Crashlytics, Sentry) for richer context — vitals tells you that it is crashing, your own tooling tells you why faster.
When to go full production
Complete the rollout to 100% when all of these hold:
- [ ] The release has soaked at its current percentage for your planned minimum duration
- [ ] Crash and ANR rates are at or below baseline for the full soak period
- [ ] No new crash clusters attributable to the release
- [ ] Support ticket volume and rating trends show no anomaly
- [ ] Backend/metrics dashboards (API error rates, purchase success rates) are nominal
- [ ] The team member on rollout duty explicitly signs off
Then click Complete rollout and monitor for another 24–48 hours. Full production is not the end of vigilance — it is the beginning of the widest exposure.
The mindset shift
A google play staged rollout is not a slower way to ship; it is a cheaper way to learn. Every percentage point is a question you get to ask your production environment before committing the rest of your users to the answer. Teams that internalize this ship more often, with less fear, because the blast radius of any single mistake is bounded by design.
If setting up a disciplined release process — tracks, staged rollouts, vitals monitoring, and Play Console configuration — sounds like work you would rather delegate, Play Console Store offers hands-on help getting your publishing pipeline production-ready.
Author bio: Alex Rivera is an Android engineer and technical writer covering Play Console policy, build tooling, and release engineering. He writes on behalf of Play Console Store, an independent marketplace for Android publishing services — not affiliated with or endorsed by Google LLC.
Top comments (0)