This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(297.6, 32%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESW%3C/text%3E%3C/svg%3E)
Second time this has happened for us. If a slot swap fails, it doesn't revert any changes it's already made to the slot specific variables
We use azure/CLI@v2 Github Action to swap our slot. Specifically with this inline script:
inlineScript: az webapp deployment slot swap -g group -n api --slot staging --target-slot production
If this fails for whatever reason, then it doesn't revert the changes that it's already made. It upgrades Staging to Production and changes any slot specific variables (In this case "environment"). When it fails, it doesn't revert that variable back to staging, so we end up with Staging environment pointing to Production resources.
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(99.2, 85%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGV%3C/text%3E%3C/svg%3E)
Hi @Scott Walker ,
Thank you for reaching us regarding the issue.
Azure App Service slot swaps are not transactional. If a swap fails mid‑operation, Azure does not revert configuration changes that were already applied, including environment variables. This can leave the staging slot temporarily pointing to production resources.
Please follow the below steps to resolve the issue:
az webapp deployment slot swap -g <ResourceGroup> -n <AppServiceName> --slot staging --target-slot production --action preview
WEBSITE_SWAP_WARMUP_PING_PATH=/health
WEBSITE_SWAP_WARMUP_PING_STATUSES=200
Kindly let us know if the above helps or you need further assistance on this issue.
Please "upvote" if the information helped you. This will help us and others in the community as well.
Hi @Scott Walker ,
I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?
It answers the question but can't say it was the answer that I was hoping for.
Hi @Scott Walker ,
Thanks for your update and sad to hear that still you are facing an issue.
Could you please try below alternatives:
az webapp config appsettings set -g <resource-group> -n <app-name> --slot staging --slot-settings environment=Staging
Re-apply production slot settings (if required)
az webapp config appsettings set -g <resource-group> -n <app-name> --slot production --slot-settings environment=Production
Because Azure does not roll back partial swaps, swap failures should be handled externally in CI/CD. A common approach is to detect a swap failure and immediately restore the expected configuration.
- name: Swap staging to production
run: az webapp deployment slot swap -g ${{ env.RG }} -n ${{ env.APP }} --slot staging --target-slot production
- name: Restore staging slot settings on failure
if: failure()
run: az webapp config appsettings set -g ${{ env.RG }} -n ${{ env.APP }} --slot staging --slot-settings environment=Staging ...
# Add any other slot-specific variables here
Microsoft documents that slot‑specific (“sticky”) settings must be explicitly marked as Deployment slot settings and should exist consistently across slots to avoid unexpected behavior during swaps.
az webapp config appsettings list -g <group> -n <app> --slot staging --query "[?slotSetting]"
Reference:
https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?tabs=portal#monitor-a-swap
Kindly let us know if the above helps or you need further assistance on this issue.
Please "upvote" if the information helped you. This will help us and others in the community as well.
Hi @Scott Walker ,
I Just want to know whether the comment above addressed your issue. If you need any further help, please let us know. We’re here to support you.
Hi,
I think you perhaps misunderstood me. The issue I had is solved, I'm just a little bit shocked that this is even an issue and that reverting changes on a swap failure isn't automatic
Hii @Scott Walker
I am glad that your issue is resolved. Azure App Service slot swaps are designed primarily to protect production availability, not to provide an atomic or transactional operation.As documented, a slot swap applies configuration changes and restarts instances in phases. If a failure occurs after some settings have already been applied, those changes are not automatically rolled back. Automatic reversion only exists when using Swap with Preview and explicitly cancelling the swap; it does not apply to standard swaps that fail mid‑operation.
So while this behavior is surprising, it is by design and aligns with how the platform prioritizes uptime over automatic rollback.
Reference: https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?tabs=portal
I think the swap slips cuz the lower sync‑layer writes its diff first and leaves the slot kinda half‑moved… so i just save the appsettings before the swap and drop them back with set if staging drifts and if even that won’t stick, a fresh slot is the only clean way out.