If Google Play is stuck on "Changes are being reviewed", the update is in Google's review queue and usually clears within a few days, sometimes up to seven or longer. The most common hidden cause is that Managed publishing is turned on, so approved changes wait for you to press Publish instead of going live automatically. Pushing another update does not speed this up and can restart the clock. Google does notify the account owner by email when review finishes, and the Publishing overview shows the current state.
Short answer
"Changes are being reviewed" means your app or update is in Google Play review, which per Google's review guidance can take a few days and sometimes longer than seven. It stalls on testing tracks because those updates are reviewed too, and new accounts also face testing requirements. If it is approved but not live, check whether Managed publishing is on, which holds approved changes until you publish them. You can push another update, but it replaces the in-review release on that track and can restart review rather than overwrite it instantly. Google emails the account owner when the review completes.
What "Changes are being reviewed" means
The message means you submitted a change, an app, an update, or a store-listing edit, and Google is reviewing it before it goes live. Review is standard for every release, including updates to testing tracks, and it runs on Google's side, so the status reflects a queue you cannot directly speed up from the Console.
It helps to separate two different situations that show similar wording. One is an update still genuinely in review, where waiting is correct. The other is an update that has already been approved but is being held from going live, which is a different problem with a different fix. Confirming which one you are in is the first useful step, because the actions are not the same.
Why it stalls on testing tracks
Updates to closed and open testing tracks are reviewed just like production updates, so a testing release can sit in "Changes are being reviewed" for the same reasons a production one can. The track being for testers does not skip the review; it simply targets a different audience once approved.
New developer accounts add another layer. Google requires a period of closed testing with a minimum number of testers before an app can go to production, so a testing track can appear stalled when it is actually waiting on those requirements or on the review that gates the next step. Confirm you meet the tester count and duration for your account type before assuming the review itself is stuck. This distinction matters, because contacting support about a slow review will not help if the real blocker is an unmet testing requirement you still control.
Is Managed publishing holding your changes?
Managed publishing is the most common reason an approved change never appears to go live. When it is turned on, Google reviews your changes and then holds them in a "ready to publish" state until you manually press Publish, which gives you control over timing but is easy to forget. If your update shows as reviewed yet nothing is live, check this first.
Open the Publishing overview in Play Console to see whether Managed publishing is on and whether you have changes waiting. If it is on and you want the update live now, publish the approved changes from that screen, and they typically go live within a short time rather than needing another full review. If you would rather changes go live automatically after review, turn Managed publishing off, and future approved updates will publish without the extra step.
Can you push another update to overwrite it?
You can create a new release while one is in review, but it does not instantly overwrite the in-review version. On a given track, the newer release replaces the older one, and review generally applies to the new release, so you can end up restarting the clock rather than shortcutting it. Pushing update after update usually lengthens the wait, because each new release re-enters the queue behind whatever is already there.
The better approach is to leave a genuine in-review release alone unless you need to fix a real problem in it. If you do need to change the binary, expect the new release to go through review from the start. Use a new version code, since Google will not accept a release that reuses an existing one.
Does Google notify you?
Yes. Google emails the account owner and relevant users when a review completes, whether the update is approved and published, held for Managed publishing, or rejected for a policy issue. The Play Console also reflects the outcome in the Publishing overview and, for problems, in the Policy status and App content sections.
Because notifications depend on your account email settings, it is worth confirming those are correct and monitored, especially for the owner account. If you suspect a rejection, do not wait only for an email; check Policy status and App content directly, since an incomplete declaration can hold a review without an obvious alert.
The review status flow
Knowing exactly where your release sits tells you whether to wait, publish, or fix something. The table below maps each state to its meaning and the right action.
| State | What it means | What to do |
|---|---|---|
| Changes are being reviewed | Update is in Google's review queue | Wait, up to about seven days |
| In review beyond seven days | Longer than the typical range | Check declarations, then contact support |
| Ready to publish | Approved but held by Managed publishing | Publish it from the overview |
| Rejected or policy issue | A problem was found | Fix it per Policy status |
| Live | Update is published to the track | Nothing further |
Match your situation to a row before acting. If you are simply in review under seven days, waiting is correct, and if you are in "ready to publish", the fix is to press Publish rather than to resubmit anything.
How to unblock it
Work through the likely causes in order rather than resubmitting blindly. The checklist below starts with the fastest fixes and ends with contacting support.
| Check | Action | Done? |
|---|---|---|
| Managed publishing | Confirm it is off, or publish the approved changes | [ ] |
| App content declarations | Complete data safety, content rating, target audience | [ ] |
| Policy status | Resolve any flagged policy issues | [ ] |
| Testing requirements | Meet tester count and duration for new accounts | [ ] |
| Waited seven days | If exceeded with no cause found, contact Play support | [ ] |
The most common real fix is completing an app-content declaration or publishing changes that Managed publishing was holding. Only after you have ruled those out, and genuinely passed the typical review window, is contacting Google Play support the right next step.
Scan before you submit
Review time is not the only risk; a release that clears review can still be rejected on a policy or security issue, which sends you back into another review cycle. Common triggers include requesting permissions the app cannot justify, cleartext traffic, or a secret embedded in the app, and these are cheaper to catch before you submit.
A scanner like PTKD.com analyzes your app build and reports findings ordered by severity and mapped to OWASP MASVS, so you fix them before the release enters review. To be clear about the boundary: PTKD does not speed up Google's review, publish held changes, or complete your declarations. It removes the preventable findings that would send a release back for another review round after a rejection.
What to take away
- "Changes are being reviewed" means the update is in Google Play review, which usually clears in a few days and sometimes takes longer than seven.
- It stalls on testing tracks because those updates are reviewed too, and new accounts must also meet testing requirements.
- If a change is approved but not live, Managed publishing is the likely cause; publish it from the overview or turn the setting off.
- Pushing another update replaces the in-review release on that track and can restart review, so avoid resubmitting without a real reason.
- Google emails the account owner when review completes; scan each build with PTKD.com so a rejection does not add another review cycle.
