Function App Deployment Updated Staging and Production Slot

Question

Our Azure Functions app has 3 deployment slots:

• dev
• staging
• production

The github associated with this resource similarly has three branches:

• dev
• staging
• main

The deployment center inside of Azure was used to create and link github action workflow files for the dev and staging branch.

The actions runner successfully updated the dev slot when I pushed to that branch. However, when I merged dev into the staging branch, while it did update staging, it also updated production simultaneously.

I obviously only wanted staging to be updated, but somehow the deployment updated both slots. This issue is quite severe as it updated production (aka my live code) without me telling it to, and I had no way to resolve it but get staging fully up to date, which would update production as well.

I have outlined almost everything I could find that would be relevant to this issue:

• In github, the main branch does not have a github workflow file (yml). Only the dev and staging file exist. Both were auto generated by the deployment center and do point to the correct slot name in the file, and a single deployment at that. I can say pretty confidently a github runner did not explicitly update the production slot.
• I did confirm through the actions tab, no action runner was used against the main branch.
• I verified the publish profile and action running logs clearly point to and update staging, not the main slot.
• The deployment center is not configured on the production slot, and the logs clearly say "CI/CD is not configured. To start, go to Settings tab and set up CI/CD." on said slot.
• When I push to the staging branch, my staging slot in Azure gets two deployment logs. The first is the notification of the update (Build/Deploy Logs), and the second is the Azure update (App Logs). Notably, the production slot does not have the build/deploy log linked to github (goes back to point 1), but it does have the same App Logs deployment ID, which happens after the staging slot is fully updated. This indicates Azure internally indicated the same deployment for both slots, but it wasn't triggered from github.
• Auto Swap (the configuration setting) is disabled on the staging slot.
• This function app runs on Elastic Premium Plan.

At this stage I can't stage and swap any updates to my app because it will also update production and I don't know what to do. Where else in Azure would there be some kind of 'trigger' that says when staging is updated, also update production?

Answer 1

@Jonah Largen

Thank you for using Q&A Platform

The behavior describes where deploying to the staging slot also updates the production slot, even with auto swap and CI/CD disabled on production is not normal and can be both confusing and risky. Based on the evidence and available documentation, several key points explain and help diagnose your issue:

Deployment Slot Behavior in Azure Functions

Azure Functions with deployment slots are designed so that a publish to a non-production slot (e.g., staging) should only update that slot. The production slot should only be updated via a manual or automated swap, unless there is an explicit configuration or trigger causing otherwise.

Common Causes for Production Slot Unexpectedly Updating

• Auto Swap Setting: When enabled, after deployment to the staging slot, the deployment is automatically swapped into production. You have verified this is disabled, so this should not be the cause.
• Direct Production Deployment: If an action runner or CI/CD pipeline directly targets production, but you have verified logs and workflows and confirmed this is not occurring.
• Internal Azure Logic or Misconfiguration: There have been rare cases where Azure App Service/Funtions slots can have a configuration issue, leading to both slots being updated simultaneously after a staging deployment, despite settings.
• Slot Configuration Swapping: App settings and connection strings marked as "slot setting" persist with the slot; unset values get swapped. Misconfiguration here can cause behavior where app content or logs appear out of sync with expected deployments.
• Inherited or Linked Publishing Profiles: If the staging slot is inadvertently using a profile or method that also updates production (e.g., through a shared publish profile or linked resource), both could receive the update.

Diagnostic Recommendations

• Deployment Logs Analysis: Review both the Azure portal deployment logs ("App Logs") and the GitHub Actions logs to confirm whether code updates, not just configuration changes, were pushed to both slots, and track the deployment ID. You've done this and confirmed only the App Logs are shared post-staging update, which is a critical clue.
• Check Slot Swap History: In the Azure portal under Deployment slots, check if any implicit swaps have been triggered even programmatically for the function app, especially within a tight timeframe after the staging update.
• Inspect Azure Portal Slot Configuration: Double check the "Configuration" tab for both staging and production slots to ensure neither has inherited/overlapping settings (especially connection strings and publish profiles).
• Test Manual Deploys and Slot Swaps: As a precaution, manually deploy a trivial change to staging only (outside your CI/CD pipeline) and see if production still updates. If so, this likely confirms an Azure-side internal bug or configuration drift.

Immediate Workaround

• Open an Azure Support Request: Given that all normal triggers (auto swap, CI/CD, runners, manual swaps) are confirmed not active, and the logs indicate Azure is internally tracking a deployment to both slots, escalate the incident to Azure Support. Persistent synchronization or propagation issues on the backend can only be rectified by Microsoft's engineers.
• Delay All Production-Related Deployments: Do not attempt further updates until Microsoft confirms the root cause, to avoid further unintended production releases.
• Audit All Slot and Resource Connections: Ensure staging and production have NO overlapping settings beyond necessary slot-specific settings, and that the deployment user/identity is scoped only to the intended slot.

Conclusion:

What you are experiencing is not a standard or expected behavior of Azure Functions deployment slots and requires Azure Support intervention. Continue to collect all deployment logs, slot configurations, and workflow files for analysis by Microsoft. In the meantime, avoid updating the staging slot if production stability is critical.

If further diagnostics/analysis of your YAML or portal settings is needed, provide sanitized screenshots or configuration files for deeper review.

I hope this helps in resolving the issue, do let me know if you have any further questions on this.