If I'm rejected, do I have to redo closed testing from the start?

It depends on the reason. If you were rejected because your answers were thin, you can improve them and apply again. If the testing itself didn't meet the requirement, you need to test more.

Will Google tell me why I was rejected?

The review result is sent to the account owner's email, and a notice appears on your app dashboard. The reason often isn't specific, though, so it's quicker to go through the requirement and your answers one by one.

You can apply once you meet the requirement again. Rather than resubmitting the same thing right after a rejection, fix what was missing and give it a few days before you apply.

Is my app deleted if I'm rejected?

Only production access is denied; the app isn't deleted. Your closed testing track stays as it is.

← Blog

Requirements

7 reasons Google Play production access gets rejected, and how to fix them

Rejections usually mean the test fell short of the requirement, or the test happened but you couldn't explain it. From too few testers, a broken test period, a weak questionnaire, no updates, and policy violations to first-launch errors and inaccurate answers, here's what to fix for each reason.

Last checked Oct 7, 2026.

Rejections usually come down to one of two things

Production access is usually denied because either the testing didn't meet the requirement, or the testing happened but wasn't explained well. The first is about the 14 days and the headcount; the second is about the questionnaire. Go through the seven reasons below from the top, and you'll find what tripped you up in most cases.

1. Fewer than 12 testers took part

What counts isn't how many emails are on the list, but how many accounts actually opted in and stayed opted in. If you drop below 12 at any point, the requirement breaks at that moment.

How to prevent it: Start with extra testers. If you start with exactly the minimum, one dropout sends you back to the beginning.

2. The 14 days weren't continuous

Testing for a few days, pausing, and starting again doesn't add up. Creating a new track or pausing the track also breaks the run.

How to prevent it: Don't touch the track or the tester list for 14 days. Adding testers is fine; avoid removing them.

3. The questionnaire answers were thin

This is the most common reason. A person reads and judges your answers, so something like 'Testing went well' is treated as having no evidence behind it.

How to prevent it: Write what you checked and what you fixed, with numbers. What you changed in each version is especially important.

4. The app never changed during testing

You're asked whether you applied what you learned from testing, and with only one version there's nothing to point to. It's not a strict requirement, but it works against you.

How to prevent it: Ship even small improvements every 3–4 days during testing to build up a version history.

5. The app itself has a policy issue

Sometimes you're blocked for reasons unrelated to testing, such as requesting too many permissions, a missing privacy policy, or a content rating mismatch.

How to prevent it: Separately from testing, get your app content, Data safety form, and privacy policy in order first.

6. Problems showed up on first launch

An app that installs but closes immediately on certain OS versions, or gets stuck on the sign-in screen, is seen as not ready.

How to prevent it: Check that first launch works across multiple manufacturers and OS versions, and keep logs from failing devices so you can fix them.

7. The answers didn't match the facts

If you make up tester experiences that never happened, reviewers can spot inconsistencies with your other answers. If it becomes an issue, it's your account that's at risk, not just the app.

How to prevent it: Write only what actually happened. It's safer to say you couldn't check a feature than to claim you did.

Before you apply again

Double-check that the headcount and duration were actually met. See the 14-day counting rules.
Rewrite your questionnaire answers. We collected question-by-question examples in How to answer the production access questionnaire.
Write down the versions you shipped during testing and what changed. This is your strongest evidence.
Make sure nothing is missing in your app content, Data safety form, or privacy policy.

If your production application is rejected, let us know within 30 days of the test ending and DUIRE will run another 14 days of closed testing at no extra cost. When re-running, it's sometimes better to create a new track, so we decide together after looking at the rejection reason.

Frequently asked questions

If I'm rejected, do I have to redo closed testing from the start?: It depends on the reason. If you were rejected because your answers were thin, you can improve them and apply again. If the testing itself didn't meet the requirement, you need to test more.
Will Google tell me why I was rejected?: The review result is sent to the account owner's email, and a notice appears on your app dashboard. The reason often isn't specific, though, so it's quicker to go through the requirement and your answers one by one.
When can I reapply?: You can apply once you meet the requirement again. Rather than resubmitting the same thing right after a rejection, fix what was missing and give it a few days before you apply.
Is my app deleted if I'm rejected?: Only production access is denied; the app isn't deleted. Your closed testing track stays as it is.

Meet the requirement without recruiting testers

DUIRE joins your closed test with real Android devices and opens your app every day for 14 days. Registering your app and checking installability are free.

Check installability See how it works