Static Web App deployments fail with "Failure during content distribution" - build succeeds, retries fail identically

I have found a solution:

For info - see GitHub Issue #1803. StevenPearson's solution fixed this issue for me:

removing skip_app_build: true from the pipeline resolved it - Microsoft appear to have changed deployment behaviour around 30 Aug so that flag now causes the content distribution failure.

In DevOps: Repos > Files > azure-pipelines.yml > Edit and delete the line: skip_app_build: true # do not run a build - just publish the files

Hi Rob,

Your diagnosis looks right to me: a deterministic failure at the same ~16-second mark on every attempt, with a successful build/upload, a tiny payload, and zero pipeline changes since the last good deploy, is the signature of the resource's content-distribution backend being in a stuck state rather than anything on your side. This matches the thread you linked, and it's a long-recurring pattern on the SWA GitHub repo as well; multiple reports describe deployments suddenly failing with "Failure during content distribution" where retrying always fails the same way despite nothing changing, and at least one recent case showed the same build-succeeds/distribution-fails pattern with a small file count well below any limit. GitHub + 2

Only Microsoft can clear the backend state for a specific resource, so the practical question is how to get eyes on it without a support plan. Three routes, in order of effectiveness:

1. Keep this Q&A thread active and post your deployment IDs. Microsoft support engineers monitor the azure-static-web-apps tag and do pick up resource-specific backend issues here in a similar content-distribution failure thread. The Microsoft responder asked the poster to continue via private messages so they could collect details and troubleshoot the specific resource. Edit your question to include the deployment IDs and exact UTC timestamps now rather than waiting to be asked; it speeds things up considerably. Don't post the full subscription ID publicly; the resource name, region, and deployment IDs are enough for them to locate it once they engage privately. Microsoft Learn

2. Open an issue at github.com/Azure/static-web-apps. The deployment failure output itself directs you there, and the SWA product team triages that repo directly; it's often faster than Q&A for backend-stuck resources. Include the resource name, region, deployment IDs, and a link back to this thread.

3. While you wait, a few things that have unstuck this for others (worth trying since they cost minutes):

• Regenerate the deployment token ("Manage deployment token" in the portal), update your DevOps secret, and redeploy. In the thread you linked, the poster had already tried this without success, but it's the cheapest possible fix, so it's worth one attempt.
• Deploy once via the SWA CLI (swa deploy) with the token directly, bypassing the DevOps task entirely. If that also fails at the distribution step, it further confirms the backend is stuck (useful evidence for Microsoft); if it succeeds, the problem is narrower than it looks.
• As a last-resort mitigation if the site being un-updatable becomes urgent: stand up a parallel Static Web App, point the pipeline at it, validate, then move the custom domain across. Not a fix, but it restores your ability to ship while the original resource is investigated.

One more note: since "Diagnose and solve problems" is erroring on the resource too, mention that explicitly when Microsoft engages a second broken control-plane surface on the same resource strengthens the case that the resource state itself is corrupted rather than anything deployment-side.

Hope you get the linked case cleared quickly; it suggests that once the right team sees it, the fix on their end is fast.