There is a setting in Play Console that catches every new publisher off guard: the staged rollout percentage. It is the thing standing between a clean release and a one-star review storm. When you ship an update, you do not have to push it to all of your users at once. You can send it to a small share of them, watch the numbers, and then either continue or halt.
Most first-time publishers go to 100 percent on day one. That works fine until the day a regression slips through, and then your entire install base has the broken build. This guide covers what Google's documentation says the percentage actually does, the ladder I use, what to watch at each step, and what halting can and cannot undo.
What is a staged rollout on Google Play?
A staged rollout releases an app update to a percentage of your users that you choose, instead of everyone at once. Google Play picks those users at random. You raise the percentage manually as your confidence grows, and you can halt the rollout at any point to stop more users receiving the update.
The rules come from Play Console's help page, Release app updates with staged rollouts. Four of them matter before you touch the setting:
- Updates only. Staged rollouts cannot be used when you publish an app for the first time. Your safety net for a first release is testing, which is one more reason the closed testing period with 12 testers is worth taking seriously.
- Random selection. New and existing users are both eligible, and they are chosen at random for each new release rollout. You do not pick who gets the build, and being in the first 5 percent of one release says nothing about the next.
- Nothing is automatic. The percentage does not increase by itself. If you start at 5 percent and forget about it, it stays at 5 percent.
- Countries only grow. You can start a staged rollout in a limited set of countries, but once it has started you cannot remove any of them.
Staged rollouts are not limited to production. The help page's steps name the Production, Open testing, and Closed testing pages. On a testing track the audience is your testers instead of your whole user base, so the percentage applies to them.
What percentages can you set?
You can set any rollout percentage you like. Play Console gives you a field where you enter the number, so you are not limited to preset steps. In the Google Play Developer API the same setting is userFraction, a value greater than 0 and less than 1. At 100 percent the release is complete and served to all users.
To change it later, open the Production page (or the testing track's page), select the Releases tab, and under the release choose Manage rollout, then Update rollout. Enter the new percentage and confirm. There is no schedule to configure. It is a number you own.
A 5 percent rollout means roughly 1 in 20 of your users is eligible for the new build. The other 19 stay on the version they have.
Which percentage should you start with?
For most feature updates, start at 5 percent. Drop to 1 percent when the release contains new native code, new permissions, or changes to sign-in. Hold each stage for about a day, then step to 20, 50, and 100 percent if the numbers stay clean. This ladder is my own practice, not a Google rule.
| Stage | When I use it |
|---|---|
| 1% | Releases with new native code, new permissions, or anything that touches authentication. |
| 5% | The sane default for any feature release. |
| 20% | After the 5 percent stage has shown clean metrics for at least 24 hours. |
| 50% | The last gate before full. Useful for catching bugs that only appear at scale. |
| 100% | Only after the previous stages have been clean for a full day or longer. |
Starting at 5 percent and stepping up adds maybe two days to a release. That is a small cost compared to the alternative.
One adjustment for small apps: a percentage is only as useful as the number of people behind it. With 2,000 active users, 5 percent is 100 people and 1 percent is 20. A crash that hits one user in fifty may not show up at all in a group that size, and Android vitals shows no data when there are too few data points for the filters you have selected. If your user base is small, think in absolute users instead of percentages. I would rather start a small app at 20 percent and learn something than hold it at 1 percent and stare at an empty chart.
What to watch while the rollout is live
Open Android vitals in Play Console and compare the new version against the previous one. Vitals data can be broken down by the app version an issue occurred on, which is exactly the comparison a staged rollout exists to give you. Two metrics matter most: user-perceived crash rate and user-perceived ANR rate.
Google's published lines are the anchor. An app is over the bad behavior threshold when at least 1.09% of daily users experience a user-perceived crash, or at least 0.47% experience a user-perceived ANR, across all devices. The per-device threshold is 8% on a single phone model. Google Play generally looks at the last 28 days of data, but its help page adds that it may act sooner in the event of a spike. The full picture is in my guide to the Android vitals bad behavior thresholds.
Those thresholds tell you where the cliff is. They do not tell you when to halt a rollout, and Google publishes no halt trigger. So here is mine, and it is a personal rule of thumb, not Google guidance: if the new version's crash-free user rate is more than 0.3 percentage points below the previous version's, and the sample is above a few thousand users, I halt.
Two notes on that rule. First, "crash-free users" is the Firebase Crashlytics way of counting: the percentage of users who used the app in a period and did not crash. Play Console counts the opposite, the share of daily users who did. Either works for comparing two versions, as long as you compare like with like and do not mix the two tools. Second, 0.3 points is large relative to Google's line. An app sitting at a 0.5% user-perceived crash rate that gets 0.3 points worse is at 0.8%, most of the way to 1.09%. I would much rather find that out from 5 percent of my users.
Also check the Crashes and ANRs page for clusters that exist only in the new version. A brand new stack trace is a stronger signal than a small move in a rate.
The thresholds are measured over 28 days, so every bad day you ship to everyone stays in your numbers for four weeks. A staged rollout limits how much weight a bad day carries.
What happens when you halt a staged rollout?
Halting stops the update from reaching anyone new. Users who already received the version stay on it, and nothing is uninstalled or reverted. From there you have two options: resume the same release if it turns out to be fine, or roll out a new release with a fixed app bundle.
To halt, go to the Releases tab and choose Manage rollout, then Halt rollout. To resume, choose Manage rollout, then Resume rollout, set the percentage, and confirm. In the Google Play Developer API the same actions are status changes: you set the release to halted, and back to inProgress to resume.
{
"releases": [{
"versionCodes": ["99"],
"status": "halted"
}]
}Halt first and investigate second. A halt costs you very little, because resuming takes a few clicks. My other rule of thumb: a rollout that has been sitting halted for more than 24 hours is usually telling you the answer is a hotfix, not a resume.
Can you roll back a release on Google Play?
No. Google Play has no rollback that returns users to an older build. Android blocks installing a lower version code over a higher one, so a user who updated stays updated. The fix is a new release with a higher version code, containing either the repaired code or the previous version's code.
This is the part people expect to work differently. Android's versioning documentation says the system uses versionCode to protect against downgrades, by preventing users from installing a build with a lower code than the one already on their device. So "rolling back" really means rolling forward: you rebuild the last good code with a new, higher number and ship that. You also cannot reuse a number you have uploaded before, which is covered in what to do when a version code has already been used.
A hotfix is a new release, so it waits for review like any other update. Knowing how long Google Play review takes tells you how long the affected users will be stuck, which is the real argument for keeping that group small.
There is one newer option for a release that has already reached everyone. The Google Play Developer API documentation describes halting a completed release, which makes it unavailable to new users and to existing users who have not upgraded yet. It only works if the track already has an earlier completed release to fall back on, and it still does not downgrade anyone who has the bad build.
Where IOn Emit fits
Setting the percentage is a small step, which is why it gets skipped under release-day pressure. IOn Emit, our Windows desktop app for Google Play publishing, puts it in the release flow: the listing editor covers all four release tracks with staged rollout control, and Quick Push lets you pick the app, drop in the bundle, and select the track and rollout percentage. The publishing suite is in the free tier.
Staged rollout checklist
- Confirm it is an update. A first release cannot be staged, so test it on a testing track instead.
- Write down the baseline. Note the current version's crash and ANR rates before you start.
- Pick the starting percentage. 5 percent by default, 1 percent for native code, permissions, or sign-in changes, higher if your user base is small.
- Hold each stage for about a day. Compare the new version against the old one in Android vitals.
- Halt on a clear regression. Then decide between resume and hotfix within a day.
- Ship fixes forward. A hotfix is a new release with a higher version code. There is no rollback.
- Finish the rollout. Raise it to 100 percent yourself. It never gets there automatically.
This post is part of our app publishing guides for indie Android developers.