When a TestFlight build expires mid-test

Record the blocked participant’s context

Ask for the invitation route, build number if visible, device and the message shown. Keep personal account details out of shared reports. Compare the tester’s experience with the current group and build state. Do not promise that every invitation remains usable indefinitely; include a planned testing window and check availability before sending a new batch of links.

Publish or assign a usable replacement

Confirm that the replacement build reaches the intended external group and has the required review status. Validate installation as a fresh tester. If the replacement also changes product behavior, update the brief and mark the reports by build. A tester’s observation about build 10 should not be merged silently with a later report about build 12.

Reset the task fairly

Explain what changed and which part of the assignment needs repeating. Preserve useful work already submitted, and do not classify an access failure as a negative public opinion. Recheck the distribution conditions rather than adding rewards to solve an access problem. A short follow-up focused on the unavailable journey is usually more useful than making every participant start the whole research plan again. Identify both the replacement build and the task so old reports remain interpretable.

Your next steps

• Check the console’s current build and group state.
• Verify the replacement with an external tester.
• Label all reports by build.
• Repeat only the work needed for the next decision.