Using a staged rollout around your first production release

A staged rollout releases a new version to a percentage of users first, so you can catch problems before everyone gets them. There is a catch for new apps: Google's help page says staged rollouts "can only be used for app updates, not when publishing an app for the first time." So depending on how Play Console treats your first production release, you may only be able to stage the updates that follow it.

What a staged rollout is

On a staged release, you choose a percentage (for example 10%) and only that share of eligible users receive the new version. According to Google's staged rollouts help page:

• new and existing users "are chosen at random for each new release rollout"
• the percentage "won't increase automatically"; you raise it yourself
• you can halt a rollout, and users who already received the version keep it
• staged rollouts are available on the Production, Open testing and Closed testing tracks

Google may change these details, so check the help page before you rely on a specific behavior.

Can you use it on your first production release?

This is the part that surprises developers coming out of closed testing. The help page restricts staged rollouts to app updates. Your app has already been published on a closed track, so whether its first production release counts as "publishing for the first time" is something Play Console decides, not something you can choose.

The practical approach:

1. Create your production release as usual (our article on next steps after production access is approved covers the preparation).
2. When you review the release, look for the Staged rollout section and a rollout percentage field.
3. If it is there, you can stage the release.
4. If it is not, release to 100% and use a staged rollout for your first update.

Either way, the safety work you did in closed testing is what protects your first release. A staged rollout is a second layer, not a replacement.

How to start a staged rollout

Google's documented flow, in short:

1. Open the Production page (or Open testing / Closed testing).
2. Select the Releases tab and click Edit on the release.
3. Scroll to the Staged rollout section and enter a percentage.
4. Start the rollout.

The release still goes through review like any other change, and if you use managed publishing, it waits for you to publish once approved.

Choosing a percentage

There is no official "right" number. Think about how many users you need before the data means anything.

• Small audience at launch: a tiny percentage of very few users tells you almost nothing. A larger first step, or a plain 100% release, can make more sense.
• Existing audience (an update): start small, for example 5–20%, and widen once you see the crash and ANR numbers hold steady.
• Risky change (new login system, payments, database migration): start smaller and hold longer.

Those numbers are common practice, not a Google rule.

When to increase, and when to halt

Before raising the percentage, check:

• Android vitals for the new version: user-perceived crash rate and ANR rate
• Reviews that mention the new version
• your own backend logs and error reports

If the numbers look normal, use Manage rollout > Update rollout to raise the percentage. If something is clearly wrong, use Manage rollout > Halt rollout. Google says that when halted, "no additional users will receive the app version," while users who already have it stay on it.

Halting does not roll anyone back. To fix the users who already have the broken version, ship a new build with a higher version code that corrects the problem.

Resuming after a halt

You can resume a halted rollout from the same Manage rollout menu and set the percentage again. Only resume if you are confident the issue does not affect most users, or was caused by something outside the app (for example a server problem you have since fixed). Otherwise, ship a fixed build as a new release instead.

Using your closed track as the first stage

Your closed test is still available after production access, and it is a useful stage before any rollout percentage:

1. Upload the new build to the closed track.
2. Let your testers use it for a few days.
3. Read their private feedback under Monitor and improve > Ratings and reviews > Testing feedback.
4. Promote the build to production with a staged rollout.

This is close to Google's own advice to keep closed tests running "while resolving user-reported issues and bugs." For how version codes work when you ship updates, see updating your app during a closed test.

Key takeaways

• Staged rollouts are for updates; your very first production release may have to go out at 100%.
• The percentage only changes when you change it.
• Halting stops new users from getting the version but does not undo it for existing ones.
• A closed track is a good pre-production stage for every update.

If you have not reached production yet, start with our guide and the production access walkthrough.