When Google Play is frozen on "Changes are being reviewed," the update is in review and the right move depends on how long it has been and whether a cause is visible: wait if you are inside the normal window, resubmit only for a real fix, and contact support once you clearly exceed it. Review usually clears within a few days and can take longer than seven in some cases. Resubmitting rarely helps and often restarts the clock. What follows is a realistic timeline and a simple decision path for whether to wait, resubmit, or escalate.
Short answer
"Changes are being reviewed" means your update is in Google Play's review queue, and the decision of what to do next is driven mainly by elapsed time. Per Google's review guidance, review usually takes a few days and can exceed seven in some cases, so inside that window the answer is to wait. Resubmitting a new release replaces the one in review and generally restarts the clock, so do it only to fix a real problem, with a new version code. Contact Google Play support once you clearly pass the typical window with no cause found in your declarations or policy status. Do not cancel and resubmit out of impatience, since that usually lengthens the wait.
What the status means
It means Google is reviewing your submitted change before it goes live, which is standard for every release, including updates to testing tracks. The status itself does not indicate a problem; it indicates a queue. What it does not tell you is whether the review is progressing normally or whether something is holding it, which is why the useful signal is elapsed time, not the status text.
Keep one distinction in mind. A change that is genuinely in review is different from one that has already been approved but is not yet live, and the two can look similar at a glance. If your change was approved and is simply not published, that is a publishing question rather than a review wait, and this decision path is about the review wait itself.
How long should it stay there?
Most reviews clear within a few days, and Google notes that some can take longer than seven days, particularly for new apps and testing tracks. So a status that has been frozen for a day or two is well within the normal range, and there is nothing to fix during that time. Treat anything under a few days as expected.
Beyond about seven days with no movement, you are outside the typical window, and it becomes reasonable to investigate and, if needed, to contact support. Google does not promise a fixed time, so treat these as ranges rather than guarantees. The key point is that the correct action changes with elapsed time, which is why you track the clock rather than refreshing the status. Note the exact time the change entered review, because a reliable start point is what lets you judge an over-run instead of relying on how long the wait feels.
Should you wait or resubmit?
Inside the normal window, wait. There is no benefit to resubmitting a release that is progressing normally, and a new release generally replaces the in-review one and restarts its review, so you lose your place in the queue. Resubmitting out of impatience is the most common way developers accidentally extend their own wait.
Resubmit only when you have a real reason, such as a genuine bug or policy fix that the in-review build needs. In that case, accept that review starts over, and use a new version code, which Google requires. If you simply need to test something while the review proceeds, use a testing track or an internal tester rather than touching the release that is in review. That way you keep making progress without disturbing the queue position of the update you actually want live.
Exact steps to unblock it
When a review runs long, the cause is often something you control rather than the queue itself. Check that all app-content declarations are complete, since a missing data-safety, content-rating, or target-audience declaration can hold a review. Confirm there are no unresolved issues in the Policy status, and, for a new account, that you meet the testing requirements that gate production access.
Also confirm the change is not simply being held rather than reviewed. If Managed publishing is on, an approved update waits for you to publish it, which can look like a freeze. Ruling these out usually explains a long wait, and only after they are clear is the queue itself the likely cause worth escalating.
When to contact support
Contact Google Play support once you clearly exceed the typical window, roughly seven days, with no movement and no cause found in your declarations, policy status, or publishing settings. At that point the delay is likely on Google's side, and support is the appropriate step. Include your app, the track, and when the change entered review.
Keep expectations realistic. Contacting support after a genuine over-run is reasonable, but it does not guarantee an immediate result, especially during a general backlog. Escalating too early, while you are still inside the normal window or before checking your own declarations, tends to waste time rather than save it.
Wait, resubmit, or escalate?
The right action follows directly from how long it has been and whether a cause is visible. The table below turns that into a simple decision.
| Situation | Elapsed time | Action |
|---|---|---|
| In review, no visible issue | Under about seven days | Wait |
| Approved but not live | Any | Publish it (Managed publishing) |
| Incomplete declaration | Any | Complete it in App content |
| Real bug or policy fix needed | Any | Resubmit with a new version code |
| No cause and no movement | Over about seven days | Contact Play support |
Read your situation against the table before acting. Most frozen statuses fall into the first rows, where waiting or fixing a declaration is correct, and only the last row, a clear over-run with no cause, calls for support.
Unblock checklist
Before you escalate or resubmit, run this short check. It covers the causes you actually control, in the order worth checking them.
| Check | Action | Done? |
|---|---|---|
| App content | Complete data safety, content rating, target audience | [ ] |
| Policy status | Resolve any flagged policy issues | [ ] |
| Managed publishing | Confirm it is not holding an approved change | [ ] |
| Testing requirements | Meet tester count and duration for new accounts | [ ] |
| Elapsed time | Only escalate after about seven days with no cause | [ ] |
The two that resolve most long waits are completing an app-content declaration and confirming Managed publishing is not simply holding an approved change. Work these first, and reserve resubmitting and contacting support for after they are ruled out.
Scan before you submit
A release that clears review can still be rejected on a policy or security issue, which sends you back into another review cycle and another wait. Common triggers include permissions the app cannot justify, cleartext traffic, or a secret embedded in the build, all cheaper to catch before submitting.
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 or publish a held change. It removes the preventable findings that would send a release back for another review round.
What to take away
- "Changes are being reviewed" means the update is in Google Play's review queue, and the right action depends on elapsed time.
- Most reviews clear within a few days and can exceed seven in some cases, so inside that window the answer is to wait.
- Resubmitting generally replaces the in-review release and restarts the clock, so do it only for a real fix, with a new version code.
- Before escalating, complete app-content declarations, check Policy status, and confirm Managed publishing is not holding an approved change.
- Contact support only after a clear over-run with no cause found, and scan with PTKD.com to avoid a rejection that restarts review.
