Open testing approval in the Play Console normally takes a few hours to 7 days, the same review pipeline as production, and is often done within a day or two, though Google gives no guaranteed time. A first open-testing release and newer accounts sit at the longer end. There is also a catch for new personal accounts: open testing is only available once you have production access, which itself requires completing the closed-testing requirement first. Resubmitting restarts the review, so wait rather than reupload, and use internal testing to keep iterating in the meantime.
Short answer
Expect a few hours to 7 days, sometimes longer. Open testing is reviewed like production, so per Google's Play Console Help, review can take from a few hours up to 7 days, with no fixed guarantee, and Google suggests a buffer of at least a week. A key point for new personal accounts: open testing becomes available only after you have production access, which requires running a closed test with at least 12 testers for 14 continuous days first. Resubmitting a new release restarts the clock. Escalate only after you clearly pass 7 days.
How long does open testing approval take?
Open testing approval normally takes a few hours to 7 days, and often clears within a day or two. Google does not promise a fixed time, so any figure is an average rather than a deadline. The first open-testing release of an app, and releases from newer accounts, tend toward the longer end because they get a fuller review.
Plan around the upper bound. If you have a date tied to your open beta, submit a couple of days ahead, because a review that usually clears in hours can still take up to 7 days, and developer reports show occasional cases running one to two weeks during backlogs. Building in that buffer keeps a beta launch from slipping.
Open testing is reviewed like production
The reason open testing takes as long as it does is that it is a reviewed track, on the same footing as production. Unlike internal testing, which reaches your own testers with minimal review, open testing distributes your app to the public, so Google reviews it the same way it reviews a production release. That is why the timeline matches production rather than the near-instant internal track.
This also means the same things that speed up or slow down a production review apply to open testing. A complete listing, an accurate Data safety form, and only justified permissions help; a first release, a new account, sensitive permissions, or a backlog slow it down. Treat an open-testing submission with the same care as a production one.
The catch for new accounts: open testing needs production access
Here is the detail that surprises many developers: on a new personal account, you cannot jump straight to open testing. Google's setup documentation states that open testing becomes available only once you have production access, and getting production access requires running a closed test with at least 12 testers, opted in for 14 continuous days. The table below shows how the tracks compare.
| Track | Reviewed? | Typical wait | Availability for new accounts |
|---|---|---|---|
| Internal testing | Minimal review | Minutes | Available right away |
| Closed testing | Yes | Hours to 7 days | Available, and required first |
| Open testing | Yes | Hours to 7 days | Only after production access |
| Production | Yes | Hours to 7 days | After the closed-testing gate |
So if you are on a new personal account and open testing is not available or seems blocked, the cause is usually not a slow review; it is that you have not yet completed the closed-testing gate. The path is internal or closed testing first, then the closed-testing requirement and production access, and only then open testing. Knowing this saves you from waiting on a review that is not actually pending.
What normal vs abnormal looks like
Normal is a few hours to 7 days in review for an open-testing release, with faster times common and longer ones possible during a backlog. Within that window, a status that looks stuck is almost always just the queue, and the right move is to wait. First releases and new accounts naturally sit toward the longer end.
Abnormal is clearly past 7 days with no movement, especially when other developers are not reporting the same. Before you treat it as stuck, rule out the two look-alikes: a status of Pending publication means the release is approved and Managed Publishing is holding it for you to publish, and a lack of production access on a new account means open testing was never actually submitted. Those explain most cases that feel abnormal but are not.
What slows an open-testing review down
Several factors push an open-testing review toward the long end, and most are the same as for production. A first release on a brand-new account, an app requesting sensitive permissions such as location or SMS, incomplete declarations like the Data safety form, and periodic deeper policy checks all lengthen the queue. General backlogs and holidays add time that has nothing to do with your app.
Most of these are within your control before you submit. Completing your listing and Data safety form, justifying every permission, and shipping a clean build remove the avoidable delays, leaving only the structural ones like account age and backlogs to plan around. A submission with nothing for a reviewer to question is the one most likely to clear quickly.
Does resubmitting reset the clock?
Yes. Creating a new release to replace the one in review restarts the process and sends you to the back of the queue, so an impatient resubmit usually makes the wait longer, not shorter. The review was likely to complete on its own, and you just reset it.
Resubmit only when you actually changed something that needs a new review, such as fixing a policy issue Google flagged. If the build is fine and simply slow, leave it in place, and use internal testing, which has minimal review, to keep iterating with your own testers while the open-testing release is pending. That keeps you unblocked without touching the release in the queue.
Are weekends and holidays different?
They can be. Google reviews on all days, but around weekends and major holidays a review can run slower because capacity is lower, and there is no guaranteed time in any case. Plan a little extra buffer around those periods rather than assuming the usual speed.
If you have an open beta tied to a specific date, submit a few days early so a slower weekend or a holiday backlog does not push your review past your launch. The cost of submitting early is nothing; the cost of cutting it close is a beta that goes live late.
When to contact support
Contact support when you clearly pass 7 days with no movement and none of the ordinary explanations apply. Use the Play Console Help and get-support flow, and include your app's package name, the open testing track, the submission time, and a screenshot of the status. Concrete details keep your case from bouncing back for more information. The table below summarizes what to do in each situation.
| Situation | What to do first | Contact support? |
|---|---|---|
| Under 7 days | Wait, it is normal | No |
| New account, open testing unavailable | Complete closed testing and production access | No |
| Status is Pending publication | Publish it via Managed Publishing | No |
| Over 7 days with no movement | Check Policy status, then reach out | Yes |
| Policy rejection | Fix the issue and resubmit | Via the policy flow |
Keep expectations realistic. Google Play does not publish a support response time, and during a backlog replies can be slow and cannot move your app ahead of everyone else's. Escalation is the right move after a week, but it is not a guaranteed fast track.
Scan before you submit
Some open-testing delays turn into rejections, and a share of those are security and privacy issues you can catch first: an app requesting permissions it cannot justify, cleartext traffic where encryption is expected, or an embedded secret. Each rejection sends you back to the queue you were trying to clear.
A scanner like PTKD.com analyzes your .apk and returns findings ordered by severity and mapped to OWASP MASVS, so you fix permission, network, and storage issues before submitting for open testing. To be clear about the boundary: PTKD does not speed up Google's review, grant you production access, or complete your Data safety form. It removes the preventable rejections that make an open-testing review take longer than it should.
What to take away
- Open testing is reviewed like production, so approval normally takes a few hours to 7 days, with no guaranteed time.
- First releases and new accounts sit at the longer end; plan a buffer of at least a week.
- On a new personal account, open testing is available only after production access, which requires the closed-testing gate first.
- Resubmitting restarts the review; leave a slow build in place and use internal testing to keep iterating.
- Scan each build with PTKD.com before submitting so a preventable rejection does not stretch your open-testing timeline.
