Azure - Static Web App stuck on "Uploading" status

Patrick Truskowski 0 Reputation points
2026-08-21T03:06:36.4566667+00:00

Hello all,

I've been using the same static web app for at least 1 year and deployed many times (10-50 times). On August 20th, I deployed as I normally do with my az cli tool, and it hung for more than 20 minutes. When I view it in the portal, it shows as "Uploading". This has been like this for over 9 hours since it first happened.

Each deployment after fails due to timeouts with the message:

✖ Uploading failed. Error message: Retry failed after 6 tries. Retry settings can be adjusted in ClientOptions.Retry or by configuring a custom retry policy in ClientOptions.RetryPolicy. (The operation was cancelled because it exceeded the configured timeout of 0:01:40. Network timeout can be adjusted in ClientOptions.Retry.NetworkTimeout.) (The operation was cancelled because it exceeded the configured timeout of 0:01:40. Network timeout can be adjusted in ClientOptions.Retry.NetworkTimeout.) (The operation was cancelled because it exceeded the configured timeout of 0:01:40. Network timeout can be adjusted in ClientOptions.Retry.NetworkTimeout.) (The operation was cancelled because it exceeded the configured timeout of 0:01:40. Network timeout can be adjusted in ClientOptions.Retry.NetworkTimeout.) (The operation was cancelled because it exceeded the configured timeout of 0:01:40. Network timeout can be adjusted in ClientOptions.Retry.NetworkTimeout.) (The operation was cancelled because it exceeded the configured timeout of 0:01:40. Network timeout can be adjusted in ClientOptions.Retry.NetworkTimeout.)

✖ Failed to upload build artifacts.

I asked Claude to try to troubleshoot and the only thing that I could take action on was to reset the deployment token, however this did not clear the "Uploading" status and still times out on new deployments.

Please help.

Thank you,
Patrick

Azure Static Web Apps
Azure Static Web Apps

An Azure service that provides streamlined full-stack web app development.

0 comments No comments

1 answer

Sort by: Most helpful
  1. Allan Solomon Mejia 7,585 Reputation points
    2026-08-23T17:27:04.1433333+00:00

    Hello @Patrick Truskowski

    Based on what you've described, I don't think resetting the deployment token will resolve this. A deployment token controls deployment authentication; it doesn't reset or cancel an existing deployment operation already stuck in the Uploading state.

    The significant details here are:

    • The same Static Web App has deployed successfully many times previously.
    • The first deployment on August 20 remained in Uploading for more than 9 hours.
    • Every subsequent deployment fails while uploading build artifacts.
    • The client retries six times, with each request eventually hitting the 00:01:40 network timeout.
    • Resetting the deployment token made no difference.

    The SWA CLI normally uploads the generated application artifacts to the existing Static Web App using swa deploy. Microsoft documents deployment tokens as the authentication mechanism the CLI uses, so successful authentication followed by repeated artifact-upload timeouts points further into the deployment path rather than to an invalid deployment token.

    Before escalating, I would run two isolation tests.

    First, confirm that you're running a current version:

    swa --version
    

    Microsoft currently documents SWA CLI 2.0.2 or later as required because of changes to the deployment mechanism.

    Then run the deployment with verbose logging:

    swa deploy --env production --verbose silly
    

    The CLI supports the --verbose option, including the silly logging level.

    I would also try deploying the same build artifact to a temporary/new Static Web App. This is a particularly useful diagnostic test:

    Screenshot 2026-08-23 122715

    If the identical artifact deploys successfully to a new Static Web App, that would strongly isolate the problem to the existing Static Web App/deployment state rather than your build, CLI or local network.

    Microsoft documents that a normal CLI deployment should complete within a few minutes, so an Uploading operation persisting for many hours isn't normal deployment behavior.

    I would not delete and recreate the production Static Web App yet, particularly if it has custom domains, application settings, authentication configuration, or other production dependencies.

    Given how long the operation has been stuck, I think Microsoft should inspect the backend deployment state.

    Microsoft Moderator Harshitha Eligeti: Could you please help escalate this to the Azure Static Web Apps engineering/support team? The original deployment has remained stuck in Uploading for more than nine hours, and subsequent artifact uploads consistently time out even after the deployment token was reset.

    Patrick, for the escalation, I would provide:

    • Static Web App name:
    • Resource group:
    • Subscription ID:
    • Azure region:
    • Approximate first failure time (UTC):
    • SWA CLI version:
    • Deployment method/command:
    • Latest failed deployment timestamp (UTC):

    Also retain the verbose swa deploy output and any correlation/request IDs it produces, but don't post the deployment token publicly.

    Sharing these references with you:

    Microsoft – Azure Static Web Apps CLI reference

    Microsoft – Deploy with the Static Web Apps CLI

    Microsoft – Install Azure Static Web Apps CLI

    At this point, I wouldn't keep retrying deployments indefinitely. If a deployment of the same artifact to a temporary Static Web App succeeds, please post that result here as well; it would give the Microsoft team very strong evidence that the existing resource's deployment state needs backend investigation.

    Please "Accept the Answer" if this information helped you. This will help us and others in the community.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.