Detecting the Swap Status of an Azure App Service Slot with Auto-Swap Enabled

We recently built an Azure DevOps pipeline which deploys code to a staging slot. This slot has auto-swap enabled to push the app into production automatically after a successul health probe check. However, the issue we ran into, was how to fail the pipeline, when that auto-swap failed — because, frustratingly, it often fails silently, or after the pipeline is already executed.

One option is to disable auto-swap and add a dedicated swap slot task in the pipeline (which is what we eventually did). But if you want to stick with auto-swap, here’s a PowerShell script to check the last auto-swap status through Azure Monitor logs:

param(
    [string]$appServiceName,
    [string]$appServiceSubscriptionId,
    [string]$appServiceResourceGroupName,
    [string]$appServiceSlotName
)

# Set the resource Id of the app service slot
$resourceId = "/subscriptions/$appServiceSubscriptionId/resourceGroups/$appServiceResourceGroupName/providers/Microsoft.Web/sites/$appServiceName/slots/$appServiceSlotName"

Write-Host "Checking the most recent deployment swap operation for $appServiceName..."

# Get the most recent swap event from the activity log using the resourceId and sort by event timestamp
$eventLog = az monitor activity-log list --resource-id $resourceId `
--query "[?operationName.value=='MICROSOFT.WEB/SITES/SLOTS/SLOTSSWAP/ACTION'] | sort_by(@, &eventTimestamp) | [-1]" `
--output json | ConvertFrom-Json

# Ensure eventLog has a result and access status
if ($eventLog -and $eventLog.status.value -eq 'Failed') {
    Write-Host "Last slot swap failed. Error message:"
    Write-Host $eventLog.properties.Message
    exit 1
} elseif ($eventLog -and $eventLog.status.value -eq 'Succeeded') {
    Write-Host "Last slot swap completed successfully!"
} else {
    Write-Host "No swap operation found or no status available."
    }

Why We Ditched Auto-Swap (For Now)

We ended up turning off auto-swap and adding an explicit swap task in the pipeline — mostly because of timing issues. The Azure Monitor logs sometimes take a few minutes to update, so if we wanted to check for a successful swap, we’d need a timed loop to keep polling, which would drag out our deploy times. The additional swap step just works in the way that we needed.

That said, if you’re okay with a delay or just need an on-demand check, this script could be handy. Let me know if you try it out or find a better way — I’d love to hear about it!