An Azure service that provides streamlined full-stack web app development.
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:
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.