When does the 14-day closed testing clock start?

The 14-day requirement sounds simple until you are staring at a Console that says 11 testers and a calendar that says day 13.

Here is how to think about the clock without guessing.

The short answer

You need at least 12 testers who have each been opted in to your closed test for at least 14 continuous days. The clock is tied to the testers' opt-in status, not just the date you created the track.

That means:

• creating the track does not start the clock;
• adding emails does not start the clock;
• the clock starts when testers actually opt in;
• a tester who joins later starts their own 14-day count later;
• if the group drops below the requirement, you may lose eligibility.

A simple timeline

Imagine you add 14 testers and 12 opt in on day 1. Two more opt in on day 5.

• On day 14, the first 12 have completed 14 days.
• The two who joined on day 5 have completed only 9 days.
• If all 12 of the original group are still opted in, you may be eligible.
• If two of the original group leave, the two late joiners are not yet a replacement for the full window.

The safest approach is to get the group in early and keep a buffer.

Does an app update reset the clock?

A normal app update does not restart the 14 days. You can fix bugs and release new builds during the test. The test track needs to stay active and the testers need to stay opted in.

Things that can cause problems:

• removing the closed track;
• pausing or stopping the test;
• letting the tester count fall below 12;
• replacing testers late in the window;
• changing the tester list in a way that removes people who were counting.

Does the clock pause if a tester uninstalls?

The requirement is about being opted in, but the spirit of the test is real usage. A tester who opts in and never installs is not a meaningful tester. A tester who uninstalls may still be opted in, but that is not the behaviour Google is looking for.

Encourage testers to keep the app installed and use it during the window. Do not treat “still opted in” as the only success metric.

How to know you are eligible

The Production page in Play Console is the source of truth. When the requirement is satisfied, the page should show the closed-testing step as complete and allow you to apply.

Do not rely only on your own calendar. Check the Console, then confirm:

• the tester count is at least 12;
• the test has been active for the required period;
• the testers you are counting actually opted in;
• there are no policy or account warnings blocking the app.

What if you are one tester short?

You have options:

1. Add a replacement and wait for their 14 days.
2. Ask a tester who left to opt back in. Their previous time may not count continuously if there was a gap.
3. Keep the existing group stable and add a buffer for next time.

There is no legitimate way to compress the 14 days. Anyone who says they can is either misunderstanding the rule or asking you to do something risky.

A note on “continuous”

Continuous means there is no break in the tester's opt-in period. A tester who opts out on day 6 and back in on day 8 has a gap. Their continuous count restarts.

This is why a small buffer matters. If you have 14 testers and two drop off, you still have 12. If you have exactly 12 and one drops off, you are at 11.

The short version

• The clock follows tester opt-ins, not the track creation date.
• Keep 12+ testers opted in continuously.
• Updates are fine; removing the test or losing testers is not.
• Check the Production page for the official status.
• Build a buffer so one drop-off does not cost you two weeks.

Next: how to apply for production access or how to keep testers opted in.