Google Play staged rollout: percentages, halts, and fixes

A Google Play staged rollout releases an app update to a percentage of your users instead of everyone at once. Google picks those users at random for each release. You raise the percentage by hand when you are confident, or halt the rollout if something goes wrong. Halting stops new users from getting the update. It does not take the update back from people who already have it.

That last point shapes how to use a staged rollout. It limits how many people a bad release reaches. It is not an undo button.

The steps below follow Google's Play Console Help and the Android Publisher API reference. Play Console labels can change, so check the current screen before you act on a live release.

What the rollout percentage means

The percentage is the share of users who are eligible for the update. The Android Publisher API describes userFraction as the "fraction of users who are eligible for a staged release." It is not the share of users who have installed it.

Those two numbers can be far apart, especially early in a rollout. Google's staged rollout help says "it may take time for the full group to receive the update." Devices update at different times.

A hypothetical example: your app has 40,000 active users and you roll out to 10%. Roughly 4,000 users become eligible. An hour later, far fewer may actually be running the new version. To know how many are, you need data from the app itself, such as release adoption in your crash reporting tool, not the rollout percentage.

Other details from Google's documentation:

• Users are "chosen at random for each new release rollout."
• New and existing users are eligible.
• Users are not notified that they are in a staged rollout.
• The percentage "won't increase automatically." Nothing moves until you change it.

When you can use a staged rollout

• Updates only. Google says staged rollouts "can only be used for app updates, not when publishing an app for the first time."
• Production and test tracks. You can stage a release on either.
• Country targeting is production-only. By default the rollout uses your production countries. You can narrow the countries when updating a production release, but "once a staged rollout has started, you can't remove any countries."

How to raise the percentage

In Play Console, open the release on the Releases tab and choose Manage rollout > Update rollout. Enter the new percentage and select Confirm update.

There is no single correct schedule. A common pattern is to start small, wait for enough real sessions to judge stability, then increase in steps. What matters is having a rule before you start: which numbers you will check, how much data counts as enough, and who decides.

Before each increase, check:

1. Crash and error rates for the new version only, compared with the previous version over a similar window. Crash-free users vs crash-free sessions explains which rate to watch.
2. The sample size. A rate based on a few dozen sessions moves with every crash.
3. Support messages and reviews that mention the new version.
4. Core user flows, such as sign-in, purchase or sync, if you track them.

How to halt a rollout, and what halting does

Halt from the same Manage rollout menu. Google's description is precise:

• "No additional users will receive the app version in your existing staged rollout."
• "Users who already received the app version in your staged rollout version will remain on that version."

The API defines the same state: a halted release "will no longer be served to users. Users who already have these APKs are unaffected."

So halting protects users who have not updated yet. Users who already updated still need a fix.

Resume or ship a fix

You have two ways forward after a halt:

Situation	What to do
The problem was outside the app, or turned out not to be real	Resume the halted rollout. Google notes that resuming affects "the same set of users."
The app bundle itself has the problem	Create a new release with a fixed bundle and roll it out.

Google's help does not describe rolling users back to an older version. Its guidance for a faulty bundle is to "create and roll out a new release with a fixed app bundle." Plan for that: a fix that ships quickly helps more than a long debate about whether to halt.

Write down what you can and cannot see

During a rollout, keep these facts separate:

Question	Where the answer comes from
Which version is configured, and at what percentage?	Play Console or the Publisher API
How many users are actually running it?	Adoption data from the app, such as your crash reporter
Is it stable?	Crash and error rates for that exact version
Did it cause a problem?	Investigation. A crash after a rollout is a lead, not proof.

Treating the rollout percentage as an adoption number is the most common mistake. It can make a release look safer than it is ("only 20% have it") or riskier than it is.

How Specita shows Google Play releases

Specita reads Google Play track and release state with a dedicated read-only service account. It matches store releases to your Android versions by release name or version code. The read-only release summary does not include an exact staged-rollout percentage, so Specita does not show or estimate one. Actual adoption stays a separate question. The Google Play setup guide lists the permissions.