TestFlight build expired error for external group: how to fix missing build

TL;DR

Upload a fresh build, assign it to the external group, and pass beta review if the group requires it, because expired TestFlight builds cannot be revived. Builds live for 90 days from upload. Note the expiry in the release calendar, upload the replacement before the old build dies, move the group to the new build, and tell testers to update through TestFlight.

TestFlight build expired error for external group: how to fix missing build

Use this when

• External testers report the build expired or the group shows no available build.
• The build was uploaded more than 90 days ago.
• A long beta or a stalled review left one build carrying the group.

Not for this skill when

• Internal testers are unaffected by some external gates but expiry applies to everyone. If internals also fail, expiry is still likely.
• The build was removed manually. A removed build also shows as missing; re-adding is impossible, upload new.

Steps

1. Open the build in App Store Connect and confirm its expiry date has passed. Verify: the build status shows expired with its date
2. Upload a new build with a higher build number from the current release candidate code. Verify: the new build finishes processing in TestFlight
3. Assign the new build to the external group, replacing the expired one. Verify: the group lists the new build as its active build
4. If the group needs beta review for this build, submit it with test notes and wait for approval before announcing to testers. Verify: review status for the new build is approved
5. Notify testers that a new build is available and the old one will not return. Verify: testers confirm installing the new build
6. Add build expiry dates to the release checklist with a reminder two weeks before the next expiry. Verify: the reminder exists with the correct date
7. Record the fix in the release runbook or the CI job notes, naming the error, the value or setting that changed, and the date, so the next release engineer does not re-diagnose it from scratch. Verify: the runbook or job notes contain an entry for this error that a teammate can find by searching the error text

Why it happens

Apple hard-expires TestFlight builds 90 days after upload as a freshness guarantee. There is no extension, renewal or un-expire action, for any group. Teams running long betas or slow enterprise pilots hit it as a sudden missing build, but it is a calendar event that can be planned around with timely replacement builds.

In practice this failure is rarely a one-off. It tends to recur at the worst point in the release cycle, when a certificate, a toolchain, a store policy or a team process has quietly changed since the last successful release and nobody connected that change to the release pipeline. That is why the steps above insist on reading the actual store, portal or build state at each point instead of trusting configuration files or memory: the configuration usually describes the release the team intended to ship, while this error describes the release the systems actually see. Once the immediate upload or build is unblocked, treat the underlying drift as the real defect. Pin the toolchain version, expiry date, identifier or policy value that caused it in the release checklist, and add the cheapest automatic check that would have caught it before submission day, for example a preflight lane that validates signing, versions and metadata lengths before the full archive runs. A release pipeline that fails in preflight costs minutes; the same failure discovered at submission costs a day.

Variants and edge cases

TestFlight build expired 90 days fix

The lifespan phrasing; only a new build helps. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

external group no builds available expired

Group phrasing; assign the replacement build to the group. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Edge case: version train interactions

A replacement build with the same version string is fine for TestFlight; only the build number must increase. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_W8fshpc01aCYmTONPKpAcA