Google Play in review too long? What to check first

Google says Play review can take a few hours or up to seven days, and longer in exceptional cases. An update in review for two or three days is inside that range, so it isn't in review too long yet. Before you treat it as stuck, open the Publishing overview page and confirm that the change was sent for review and isn't waiting for you to publish it.

Both situations can look like a slow review, but nothing happens until someone on your team acts.

The steps below follow Google's Play Console Help. We did not test them on a live submission, and Play Console labels can change, so check the current screen before you act.

Google Play review time: how long it takes

Google's managed publishing guide says processing "can take a few hours or up to seven days (or longer in exceptional cases)," depending on the review time your app is subject to. Google recommends a buffer of at least a week between submitting and going live.

Its publishing guide adds that certain developer accounts and certain apps get extended reviews. Google doesn't publish a per-app estimate, so you can't work out your exact wait from the Console.

First, find where the update really is

Open Publishing overview and find which section lists your change. The last two rows are statuses, which appear under your app's name.

What you see	What it means	Who acts next
Changes not yet sent for review	Google has not received it for review.	You. Click Send for review.
Changes in review	Google is reviewing it.	Google.
Changes ready to publish	It is approved and held by managed publishing.	You. Publish it.
Update rejected	One or more changes don't comply with policy.	You. Fix and resubmit, or appeal.
No pending changes	Nothing is waiting.	Check that the release you expected was actually rolled out.

Google also reports status at three levels: the app, the update, and each item in the update. An app status of Production can sit alongside an update status of In review. The first says your app is available. The second is about your latest changes.

Four reasons an update only looks stuck

The change was never sent. Google says items aren't sent for review until you click Send for review. Every reviewable change collects in Changes not yet sent for review until then.

A resubmission needs another click. After a rejection, changes you make to fix the issue aren't sent automatically. You have to return to Publishing overview and send them.

Managed publishing is on. With managed publishing, an approved update waits in Changes ready to publish until someone selects Publish changes. Google says the update then goes live within a few minutes. The setting stays on until someone turns it off, so it can outlast the launch it was meant for. Check the Managed publishing status section on the same page.

The block is on the account. Personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers, opted in continuously for 14 days, before they can apply for production access. That is a separate gate from update review. If your production track is unavailable, start there. Google Play internal vs closed testing explains the tracks.

Don't restart the clock by accident

Google says the review turnaround is counted from the last submitted change. If you submit another change while earlier changes are in review, your app "may be pushed to the back of the app review queue."

Avoid sending small store listing edits while an urgent update is in review. Hold them in Changes not yet sent for review, or use Save for later, until the update clears.

You can also pull changes that are in review back into the unsent section. Google warns that removed changes may still be subject to review, which could affect your publishing plans. Treat this as a way to stop an unwanted change, and don't count on it to speed anything up.

What your users see while you wait

Your currently published version stays live during review. Google's policy status guide says that if an update is rejected, the last version you successfully published is still available on Google Play.

Internal testing can help while production waits. Google says internal track updates are usually available immediately and aren't subject to review, though they may be reviewed retroactively. There are two exceptions: an app whose first release goes to the internal track, and the next submission after a rejection. Both need review first. Those builds reach your testers only, but they let your team confirm a fix.

Check what reviewers need

Google's app review preparation guide lists the declarations on the App content page. Before you resubmit or escalate, confirm these are complete:

• Privacy policy. Google says that to prevent review delays, the policy must be on an active public URL with a valid SSL certificate, accessible worldwide without a login, and on a standard webpage instead of a PDF.
• App access. If parts of your app are restricted, give reviewers working instructions to reach them. A hypothetical example: a demo login that expired last month blocks a reviewer in the same way it blocks a user.
• Sensitive permissions. SMS or Call Log access may need a Permissions Declaration Form and approval.
• Needs attention tab. Declarations listed here have deadlines that you must meet to stay compliant.

When to contact Google

Google doesn't publish a point at which a wait counts as stuck. We suggest this rule: once a change has been in Changes in review for more than seven days, with nothing unsent and no rejection on the Policy status page, contact support from the Help page in Play Console.

Include these details so that nobody has to ask for them:

• The package name
• The version code and release name
• The date and time you sent the changes for review
• What Publishing overview shows, with a screenshot
• Your release deadline, if a real one exists

Keep credentials out of the message unless they are demo details reviewers specifically need.

If you can't wait for review

The Play Console Help pages we checked don't describe an expedited review request like the one Apple offers. Plan around that:

• Roll out in stages. A staged rollout limits how far a bad version spreads, which reduces how often you need an emergency fix in the first place.
• Keep fixes small. Send only the fix, and hold unrelated changes back.
• Fix on the server when you can. A feature flag or server-side change can reach users with no store review at all.
• Tell people the real state. "Submitted, waiting on Google, last checked at 10:00" is more useful to a client or support team than "should be live soon."

After approval, confirm the release

An approved update isn't always a finished one. Check that the rollout percentage is what you intended, that the right track received the release, and that the version code matches what you built. If a team member asks whether the fix is live, the answer should name the track, the version, and the time you checked.

Specita reads each Google Play track with a read-only service account and shows the release state, including In review, Approved, and Published. Releases match your Android versions by release name or version code, so the whole team can see where a version stands in one place. To set it up, use the Google Play setup guide.

Google guidance checked on November 4, 2026.