Back to the same issue today. It worked for a few hours then stopped working around 10am central. Pushing new commits to an PR or even closing and reopening the PR does not trigger the Xcode cloud workflow at all.

Still the same issue for me. It'll stop picking up builds for hours at at time then all of a sudden a bunch of builds will get triggered at once. Meanwhile I'm wasting Xcode Cloud compute minutes on all these failed builds, which means I may need to end up purchasing more compute minutes as a result of Apple's own bugs with Xcode Cloud.

Update, six hours on: the degradation has moved a level deeper. This morning the PR was ingested and a manual API start worked around the dead trigger; tonight PR ingestion itself has stopped, so there is no manual path either. Controlled data (all times UTC, 2026-07-24; same repo 2fa9eb0d-6b3b-4755-8534-22a039e3ccf0, same PR workflow 2ab3fb84-1c94-4ed1-a84c-b2e6ab84d054): 01:43:10 — new PR opened (clean head commit, no skip markers, base main). As before: no build run, no check on the PR. 02:11, 28 minutes later — GET /v1/scmRepositories/{repoId}/pullRequests (paginated) still does not return this PR. The newest PR it returns remains this morning's (098509a9-5243-4741-abca-877aaa5381c4). This is the step that still worked this morning. Ref ingestion is fine and now diverging from PR ingestion: GET .../gitReferences picked up the PR's branch promptly (0b5618c4-a9d4-45f1-af7f-2bfb38d7efe8). With no scmPullRequest object, the manual workaround is gone: POST /v1/ciBuildRuns with the workflow plus the branch's git reference is rejected ("The manual build cannot be created because the branch ... is not associated with the workflow" — correct behavior for a PR workflow, but it means a PR-scoped workflow currently has no start path at all), and starting the build from the App Store Connect UI doesn't work either. So the inbound pipeline has gone from "pull_request events not evaluated against start conditions" to "pull_request objects not ingested at all", while everything outbound (repo access, ref ingestion, build execution) stays healthy. Will attach this to FB23948570.

Feedback Assistant: FB23948570

Additional data from a controlled repro (all times UTC, 2026-07-23): The failure is intermittent, starting roughly Jul 20–21: automatic PR triggers have failed on several days this week (requiring manual starts, e.g. runs 604 on Jul 21 and 609 on Jul 22), yet also succeeded in between — PULL_REQUEST_OPEN/UPDATE runs fired normally at Jul 22 23:51 (build 611), Jul 23 02:24 (612), and Jul 23 05:36–06:31 (614, 616, 617). The most recent successful automatic trigger was today 06:31:56 (build 617). Today's first failure, reproduced in a controlled way: a new PR created at 19:46 (clean head commit, no skip markers, same workflow, base main) produced no build run and no check on the PR after 20+ minutes. Closing and reopening the PR to generate a fresh pull_request event also produced nothing. Meanwhile, everything on the API side works: PR ingestion: GET /v1/scmRepositories/{repoId}/pullRequests returns the new PR with correct metadata (SCM PR id 098509a9-5243-4741-abca-877aaa5381c4). Manual triggering of the same workflow against that same PR works immediately: POST /v1/ciBuildRuns (workflow 2ab3fb84-1c94-4ed1-a84c-b2e6ab84d054, that pull-request id) created run 888e622d-f3af-4c58-895a-d2f601ab6f3c (startReason MANUAL) at 20:12:17, which SUCCEEDED at 20:20:19. So Apple's outbound path (ASC → GitHub with the App installation token) is fully healthy — repo access, PR metadata, build execution all work. What's failing, intermittently, is only the inbound event path: GitHub's pull_request events reaching Xcode Cloud's start-condition evaluation. These are different mechanisms, so "the integration has the permissions it needs" doesn't clear the webhook path — and since Xcode Cloud integrates as a GitHub App, its event webhook is registered on Apple's side, not in my repo settings, so I have no delivery log to inspect from my end. Repo id 2fa9eb0d-6b3b-4755-8534-22a039e3ccf0, app com.ArkonLabs.Protego.

Any updates on this?

Bump?

I re-ran the pipeline (without committing any new changes) and the whole pipeline succeeded this time.

@DTS Engineer I also don't think it's anything to do with my code (though I could always be wrong). This pipeline ran for 1hr 33min until I canceled it and none of the 3 targets finished, they all got stuck at 93%: https://appstoreconnect.apple.com/teams/411a63c1-9d73-4245-8bec-d755e3579ec7/apps/6737959724/ci/builds/ac32a2f1-0a28-446b-bae1-c3228612af8b/summary This pipeline ran for 53 minutes until I canceled it but iOS target succeeded, macOS and visionOS were stuck at 93%. https://appstoreconnect.apple.com/teams/411a63c1-9d73-4245-8bec-d755e3579ec7/apps/6737959724/ci/builds/3cb93c56-2eb4-4984-97df-879c0e83c8dd/summary BOTH of these pipeline runs were for the same exact commit, the code didnt change between them yet in one of them iOS succeeded and in the other one it didnt.

@DTS Engineer yes I submitted a request but it was through the contact us form not through feedback assistant: https://developer.apple.com/contact/case/102801901445/solution/select Case 102801901445 As far as sharing the project, here's a direct link to the pipeline: https://appstoreconnect.apple.com/teams/411a63c1-9d73-4245-8bec-d755e3579ec7/apps/6737959724/ci/builds/28aadaf4-68e2-4e10-9a18-fd69a574307d/summary

I came here to make the same post, my Xcode Cloud pipeline runs keep getting stuck at 93% but only for macOS and visionOS builds. iOS was having the same issue earlier but it's now working. I had a build stuck like that for 1.5hrs so I just decided to stop it and try again but all of them keep getting stuck.

I have the same error when using browser.storage.local.set() in my safari web extension. Have you found a fix/workaround?

Just submitted a feedback: FB20510351

@Jainesh91 did you figure this out?

Same issue here. I'll open a bug report shortly.