If your TestFlight build has been processing for hours, it is usually not permanently stuck, and the first thing to do is check Apple's System Status page for a TestFlight or App Store Connect outage, because server-side processing occasionally hangs across all developers. Processing normally finishes within minutes to about an hour, so a few hours is slower than typical but not alarming, especially during a service issue. If there is no outage and the build has been processing well beyond a normal wait with no movement, the usual fix is to upload a new build with an incremented build number, which starts a fresh processing job and clears a genuinely stuck one. A build stuck in processing does not affect any app you already have live.
Short answer
Processing for hours is usually a delay, not a permanent stall, so check for an outage before acting. Per Apple's System Status page, TestFlight and App Store Connect issues are posted there, and server-side processing can hang globally, which explains a long wait you cannot fix. Per Apple's TestFlight documentation, processing normally completes within minutes to about an hour. If there is no outage and the build is genuinely stuck well beyond that, upload a new build with a higher build number to start fresh processing. Do not cancel in a panic; a stuck build does not affect a live app, and re-uploading is the common remedy.
What processing is and how long it takes
Processing is the server-side work Apple does on your uploaded build before it is available in TestFlight, including preparing and validating the binary and its assets, and it happens after the upload completes but before you can distribute the build. During this phase App Store Connect shows the build as processing, and you cannot yet send it to testers. It is entirely on Apple's side, so it is not something your machine or your upload is still doing once the upload finished.
In normal conditions, processing finishes within minutes to about an hour, and often faster, so most builds move out of processing quickly. A wait of a few hours is slower than typical but happens under load or during minor server delays, and it does not by itself mean the build is stuck. Because processing time is variable and set by Apple's systems, there is no guaranteed duration, so you judge a long wait against the normal range of minutes to an hour rather than a fixed deadline, and treat a few hours as slow-but-possible before concluding something is wrong.
Check Apple's System Status first
When processing takes hours, the first and most useful step is to check Apple's System Status page for a TestFlight or App Store Connect issue, because a service outage is a common cause of processing that hangs for everyone. Apple posts known problems with its developer services there, so if TestFlight or App Store Connect shows an issue, your build is waiting on Apple, not on anything you did, and there is nothing to fix on your end except wait for the service to recover.
This check saves you from taking unnecessary action. If an outage is in progress, uploading a new build or contacting support will not speed anything up, because the bottleneck is the service itself, and you simply wait until Apple resolves it and the backlog clears. If System Status shows everything operational, then the delay is more likely specific to your build, which points you toward the new-build-number remedy. So checking status first tells you whether you are dealing with a global issue you must wait out or a stuck build you can act on, which are handled differently.
Should I upload a new build number?
If there is no outage and your build is genuinely stuck in processing well beyond the normal range, uploading a new build with an incremented build number is the standard fix. Each upload with a new build number, meaning a higher build version, creates a fresh processing job, so a new upload often clears a build that got stuck, because Apple processes the new one rather than the hung one. This is the most reliable self-service remedy for a truly stuck build.
Do this deliberately, not reflexively. Increment your build number so the new upload is distinct, since re-uploading the same build number will not create a new build, and submit the new build. There is no harm in the old stuck build; it simply sits, and the new one supersedes it once processed. Reserve this for a build that has clearly been stuck beyond a reasonable wait with no outage explaining it, rather than a build that is merely slow, because a new upload restarts the clock and is unnecessary if the current build would have finished on its own shortly.
Normal versus abnormal waiting
Judging your wait against the normal range keeps you from acting too soon. Processing within minutes to about an hour is normal, and a few hours is slower but still within the realm of ordinary delays, especially under load. So a build that has been processing for two or three hours is not necessarily stuck, and the right response there is usually to wait a bit longer, having checked that there is no outage.
Abnormal is a build that has been processing far beyond a few hours, into a full day or more, with no service issue posted and no movement. That is when the build is genuinely stuck rather than slow, and when the new-build-number remedy applies. The distinction matters because acting on a merely-slow build wastes an upload, while waiting indefinitely on a truly stuck one wastes time. Check the status, account for outages, and treat a wait of many hours to a day with no explanation as the threshold for taking action.
Does re-uploading reset review?
Uploading a new build does start fresh processing for that build, and if the build needs Beta App Review for external testing, the new build goes through that review as a new submission. So re-uploading to clear a stuck processing state means the replacement build processes and, where applicable, is reviewed on its own, rather than inheriting the stuck build's place. For internal testing, which does not require Beta App Review, the new build is simply processed and made available.
This is worth knowing so the re-upload does not surprise you. If your stuck build had already passed review and only processing hung, a new build will need its own processing and, for external testers of a new version, its own review. In practice, since the stuck build never became usable, starting fresh with a new build number is the way forward regardless, and the small cost of the new build processing is worth clearing a build that was not going to finish. Just do not repeatedly re-upload a build that is merely slow, since that restarts the work unnecessarily.
When to contact support
Contact Apple Developer Support when a build is stuck well beyond a normal wait, there is no outage explaining it, and uploading a new build number has not resolved it either. At that point the issue is neither a normal delay nor something the standard remedy fixed, so it warrants Apple looking into it. Provide your app and build details and describe what you have already tried, including the new upload, so support can investigate rather than suggest the steps you have taken.
Before escalating, make sure you have done the basics: confirmed there is no service issue on System Status, waited past the normal range, and tried a new build number. Support is the right step for a genuinely stuck build that resists the self-service fix, not for a build that is slow or waiting on an outage. A clear, factual request after you have ruled out the common causes is more effective than reaching out while a global issue is still in progress or before you have tried the standard remedy.
Processing status guide
Matching how long you have waited to the likely cause tells you whether to wait or act. The table below maps it.
| Time in processing | Normal? | Likely cause and response |
|---|---|---|
| Minutes to about an hour | Normal | Standard processing; wait |
| A few hours | Slower but common | Load or minor delay; wait, check status |
| Hours during a posted outage | Explained | Apple service issue; wait for recovery |
| A day or more, no outage | Stuck | Upload a new build number |
Read the table by both the time and whether an outage is posted, since the same duration means wait during an outage and act when everything is operational.
What to do checklist
Working through these steps resolves a long processing wait. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Check System Status | Look for a TestFlight or App Store Connect issue | [ ] |
| Wait out the normal range | Give minutes to a few hours before acting | [ ] |
| If an outage, wait | Do not upload or escalate during an outage | [ ] |
| If genuinely stuck, re-upload | Increment the build number and upload again | [ ] |
| Do not spam re-uploads | Only re-upload a build clearly stuck, not slow | [ ] |
| Escalate if unresolved | Contact support after the remedy fails | [ ] |
The step that decides your response is checking System Status, because it tells you whether to wait out an Apple issue or act on a stuck build, which look identical without it.
Use the wait to verify the build
Whether your build is processing normally or waiting out an issue, the time is better spent verifying the build than refreshing the status. A build that eventually processes still goes to testers and, later, review, so confirming it is sound while you wait is productive.
A scanner like PTKD.com analyzes your build and reports issues such as leaked keys and secrets, over-broad permissions, and insecure data handling by severity, mapped to OWASP MASVS, so you catch problems during the wait rather than after testers or reviewers do. To be clear about the boundary: PTKD does not process your build, contact Apple, or change your processing time. It helps you use the wait to make sure the build that finishes processing is one you are ready to distribute.
What to take away
- Processing for hours is usually a delay, not a permanent stall, and processing normally finishes within minutes to about an hour.
- Check Apple's System Status page first, since a TestFlight or App Store Connect outage can hang processing for everyone, and during one there is nothing to fix but wait.
- If there is no outage and the build is genuinely stuck well beyond a normal wait, upload a new build with an incremented build number to start fresh processing.
- Re-uploading starts fresh processing and, for external testing of a new version, a new review, so do it only for a build that is truly stuck, not merely slow.
- Escalate to support after ruling out outages and trying a new build number, and use the wait to scan your build with a tool like PTKD.com.
