Shipping an update to every user at once is a one-shot decision with no undo button. Google Play's staged rollout turns that decision into a dial: publish the update to a slice of your install base, watch the vitals, and then widen it or stop it from the Production page. In 2026 the feature covers more than the classic percentage slider — a release that has already reached 100% of users can now be halted, with a previously live version taking its place. This guide walks the whole lifecycle: choosing a percentage, restricting countries, ramping up, halting, resuming, and recovering when the fix has to ship as real code.
What a staged rollout actually controls
The feature is narrower and more specific than "release to some users", and the differences decide how you handle an incident:
- Updates only. Staged rollouts cannot be used when publishing an app for the first time — the rollout percentage options are not offered on a first release.
- Eligibility, not delivery. The update is offered to the percentage you choose; it may take time for the whole group to receive it, and users are not notified that they are inside a staged rollout.
- Selection is random per release. New and existing users are eligible and are chosen at random for each new release rollout.
- Halting keeps what already shipped. When you halt, no additional users receive that version — the users who already installed it stay on it.
- Resuming targets the same users. If you halt and later resume the same release, you affect the same set of users.
Where staged rollouts live in Play Console
The percentage is configured on the track page you are releasing to: Test and release > Production for a production update, or the Open testing / Closed testing pages for a test track. Creating a release requires the Release apps to testing tracks permission, and production releases additionally require permission to manage production releases — if the track page or the rollout controls are missing, permissions are the first thing to check.
- Internal testing — up to 100 chosen testers. The fastest loop, and the only track excluded from the halt-a-full-release feature.
- Closed testing — a limited set of chosen testers, on one or more custom tracks.
- Open testing — testers can join directly from your store listing.
- Production — everyone in the countries and regions you selected.
One operational constraint matters before any of this: you cannot create a new release while you have outstanding releases. Roll staged releases to 100% first, or remove the pending changes on the Publishing overview page and discard unpublished releases.
Starting a staged rollout, step by step
- In Play Console, open the track: Test and release > Production, or the open / closed testing page.
- Select the Releases tab and click Create new release, or Edit release on an existing one. If the button is disabled, the Dashboard still lists outstanding setup tasks.
- Add the app bundle, name the release, and write the What's new notes — release notes accept up to 500 Unicode characters per language, each language inside its own tag on separate lines.
- Click Next to reach the preview and confirm screen, and clear anything listed under the errors summary.
- In the Staged rollout section, enter a rollout percentage. Nothing here increases on its own.
- Optionally restrict the rollout under Country availability — an option that appears only when you are updating a production release.
- Click Start rollout (production: Start rollout to production).
Country-restricted rollouts
A staged rollout can start with a limited set of countries rather than the whole production footprint. By default the country availability of the staged rollout matches the locations configured for the production track. The trap is one-way: once a staged rollout has started, you cannot remove any countries from it. Choose the initial footprint as if you will have to live with a superset of it.
Increasing the percentage
On the track's Releases tab, find the release and choose Manage rollout > Update rollout, set the new percentage, and click Confirm update. The ramp is entirely manual: a release sits at whatever percentage you last set it to, for as long as you leave it there.
Treat the percentage as a paced increase rather than a slider. Lowering it does not remove the update from users who already received it — all it changes is who is eligible from that point on. If the goal is to stop exposure, halt; do not try to dial it back.
Halting a staged rollout
If you find an issue while a rollout is still partial, halt it: Manage rollout > Halt rollout on the track's Releases tab. No additional users will receive that version, and the users who already received it remain on it. Halting is containment, not rollback — the build stays on the devices that got it, so support may be dealing with two versions at once.
Halting a release that already reached 100%
Play also lets you halt a release that is already rolled out to 100% of your users — the case that used to be unanswerable. The halted version stops being served, and a previously live, fully rolled-out version automatically takes its place and becomes available to new and eligible users. The controls and limits:
- Any track except internal testing, using the Play Console web or mobile UI, or the Publishing API.
- Resume to any percentage — that is how you gradually reintroduce a release after fixing the issue.
- You cannot halt the first release on a track. If the current 100% release is the first version on that track, there is no previous release to fall back to.
- A previous release with a policy violation cannot be used in place of the halted one.
- Late halts are weak medicine. If the release has been live for a long time or is used by most of your users, most of them have already updated to the halted build.
Recovery: resume, or ship a fixed bundle
Once the rollout is stopped, there are exactly two directions forward, and picking the wrong one wastes a cycle:
- Resume — when the bundle is fine. A backend incident, a false alarm from a single crash cluster, or an issue fixed server-side needs no new build: Manage rollout > Resume rollout, pick a percentage, Confirm update. Halting and resuming affects the same set of users.
- New release — when the bundle itself is broken. Create a release with the fixed bundle and a higher version code. There is no downgrade path on Google Play: the store serves the highest version code, so "rolling back" always means shipping the old codebase again under a new, higher version number.
Watch the interaction between consecutive releases. If you start a staged rollout of a new release before the previous release has finished rolling out, the new release uses the same group of users as the previous one, depending on its percentage. Overlapping ramps therefore do not widen the test population the way developers expect.
What to watch while a rollout is live
- Release overview — installs, updates, performance issues, and ratings compared with your previous releases.
- Android vitals — crash and ANR rates are the two signals that decide whether to ramp or halt, and they should be read against the previous release rather than a fixed threshold.
- Rollout history — the timeline of when the release was halted, resumed, or served to a new user percentage. This is the audit trail for the incident.
- Ratings and reviews — users inside a staged rollout can post public reviews, so 5% exposure can still put a 1-star review on the listing.
- Store listing edits — keep them out of the rolling release window. Google recommends updating the store listing after the release reaches 100% of users.
Pitfalls that cost operators time
- Waiting for the percentage to increase by itself, then finding the release parked at 5% a week later.
- Assuming 100% is final. It can be halted now — but only when there is an eligible previous release to fall back to.
- Trying to roll back by re-uploading the old bundle with its old version code. Play rejects it; version codes must increase.
- Forgetting that a halted build remains on the devices that installed it, which splits the support surface into two versions.
- Adding countries to a staged rollout and then discovering they cannot be removed once the rollout is under way.
- Editing the store listing mid-rollout, leaving the listing out of step with the build most users actually have.
- Running many apps through rollout by hand. The Publishing API exposes tracks with a
userFraction, so setting the percentage, halting, and resuming can be scripted and logged.
The one-line model: a staged rollout controls which users are eligible for an update, not what is already on their devices. Raise the percentage in steps, read the vitals before each step, halt to stop new exposure, resume to reach the same users again, and ship a higher version code when the fix has to be real code. 100% is no longer unfixable — but the fallback is your previous release, not the damaged one.