Windows Slot-Swap Binding Drift and Worker Recycle¶

1. Summary¶

Symptom¶

A Windows App Service slot swap completes, and a worker restart appears after cutover. Responders suspect hostname-binding drift, but available evidence may also fit normal swap preparation, the documented recycle of former production instances, platform replacement, a configuration/deployment change, or an application crash.

Exact documented mechanism¶

Microsoft Learn currently says:

“After slot swaps, the app might experience unexpected restarts. The restarts happen because after a swap, the host-name binding configuration goes out of sync. This situation by itself doesn't cause restarts. However, certain underlying storage events, such as storage volume failovers, might detect these discrepancies and force all worker processes to restart.”

It then says:

“To minimize these types of restarts, set the WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 app setting on all slots. However, this app setting doesn't work with Windows Communication Foundation (WCF) apps.”

This playbook does not extend that wording. In particular, it does not claim that drift always restarts workers, that the setting prevents every restart, or that an unseen storage event occurred.

Decision flow¶

flowchart TD
    A[Worker change observed near Windows slot swap] --> B[Build UTC timeline and classify swap phase]
    B --> C{Restart during documented source-slot preparation or final former-production recycle?}
    C -->|Yes| D[Classify as documented swap-phase recycle candidate]
    C -->|No or unclear| E{Deployment, effective config, app crash, or instance replacement evidence?}
    E -->|Yes| F[Validate that competing cause]
    E -->|No| G{Binding drift plus discriminating platform evidence available?}
    G -->|Yes| H[Binding mechanism supported; preserve evidence]
    G -->|No| I[INCONCLUSIVE]
    D --> J[Do not infer hostname-binding cause]
    F --> J
    H --> K[Validate conditional mitigation only if applicable]
    I --> L[Do not induce storage failover]
    K --> M[Monitor, compare, and retain rollback]
    L --> M
    J --> M

Conclusion rule¶

Temporal adjacency is not causation. Without evidence that distinguishes the binding mechanism from other restart paths, conclude INCONCLUSIVE. Reproduction never requires inducing storage failover or another platform failure.

2. Common Misreadings¶

• “Every post-swap restart is hostname-binding drift.” The documented mechanism is conditional, and swap itself contains restart/recycle phases.
• “Binding drift alone causes the restart.” Learn explicitly says the out-of-sync state by itself does not cause restarts.
• “Setting the value on production is enough.” Learn says to set it on all slots.
• “The setting guarantees no restart.” Learn says it minimizes “these types” of restarts; it is not a universal no-restart guarantee.
• “The setting is safe for every Windows app.” Learn says it does not work with WCF apps.
• “A nearby storage event must have occurred.” If the necessary platform telemetry is unavailable, that proposition remains not proven.

3. Competing Hypotheses¶

4. What to Check First¶

Build a phase-aware timeline¶

Applicability matrix¶

Documented, observed, and not proven¶

What is not documented¶

5. Evidence to Collect¶

Required package¶

• Activity Log export for the swap window, including correlation ID, operation status, initiator, source, and target.
• Before/after PID, process start time, and approved instance marker for both slots where possible.
• Effective WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG value and slot-setting status on every slot; redact unrelated values.
• Hostname inventory and effective slot configuration without certificate material, secrets, or real customer hostnames in shared artifacts.
• Deployment/package ID and configuration-change timeline.
• Kudu Process Explorer, Windows Event Log/application log, crash/Auto-Heal evidence, and dumps only when safely collected.
• HTTP request timeline around the swap and worker transition.

Collection commands¶

az monitor activity-log list --resource-group <resource-group> --start-time <incident-start-utc> --end-time <incident-end-utc> --query "[?contains(operationName.value, 'Microsoft.Web/sites/slots/slotsswap/action')]" --output json
az webapp config appsettings list --resource-group <resource-group> --name <app-name> --slot <slot-name> --output json
az webapp config hostname list --resource-group <resource-group> --webapp-name <app-name> --slot <slot-name> --output json

Hostnames are sensitive operational data. Do not paste raw output into issues or public logs. For process evidence, follow the linked Windows Kudu diagnostics procedure with Microsoft Entra authentication and create a sanitized evidence summary; do not request publishing credentials merely to discover the SCM endpoint.

KQL: platform candidate events¶

The current table reference documents every projected AppServicePlatformLogs column below. Message searches locate candidates; they do not prove the binding mechanism or guarantee complete host telemetry.

let incidentStart = datetime(<incident-start-utc>);
let incidentEnd = datetime(<incident-end-utc>);
AppServicePlatformLogs
| where TimeGenerated between (incidentStart .. incidentEnd)
| where Message has_any ("swap", "binding", "restart", "recycle", "worker", "storage")
    or OperationName has_any ("swap", "restart", "recycle")
| project TimeGenerated, Host, OperationName, Level, Message, ActivityId, DeploymentId, Exception
| order by TimeGenerated asc

KQL: request/instance discontinuity¶

The current AppServiceHTTPLogs reference documents ComputerName, request fields, status, and elapsed milliseconds. It does not document PID or process start time.

let incidentStart = datetime(<incident-start-utc>);
let incidentEnd = datetime(<incident-end-utc>);
AppServiceHTTPLogs
| where TimeGenerated between (incidentStart .. incidentEnd)
| summarize Requests=count(), Failures=countif(ScStatus >= 500), P95Milliseconds=percentile(TimeTaken, 95) by ComputerName, bin(TimeGenerated, 1m)
| order by TimeGenerated asc

Settings-state comparison¶

For every slot, record a sanitized row:

Do not change the setting until you have this baseline and have confirmed the workload is not WCF.

Reproduction/test record¶

6. Validation and Disproof by Hypothesis¶

[Observed] Record process, instance, settings, and operation evidence from the affected environment.

[Inferred] Binding drift is only a supported explanation when evidence discriminates it from the other hypotheses.

[Not Proven] A restart near a swap does not prove an underlying storage event or hostname-binding cause.

Controlled validation of the setting¶

Only for an applicable native Windows non-WCF workload:

1. Preserve the baseline evidence package and export every slot's current setting state.
2. In a nonproduction environment, set WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 on all slots through the normal configuration pipeline.
3. Expect the configuration change itself to be a possible restart boundary; timestamp it separately from any later swap.
4. Run approved swaps without inducing storage failover. Capture the same PID/start-time, instance, Activity Log, configuration, and diagnostics evidence over multiple comparable trials.
5. Treat reduced recurrence as supportive operational evidence, not proof of a universal guarantee or proof of an unseen historical storage event.

Rollback¶

1. Stop further swaps if the app becomes unhealthy.
2. Restore the setting on every slot to its captured previous state (0 or absent) through the same controlled configuration pipeline.
3. Verify all slots report the intended prior state and preserve the change event/restart timeline.
4. If the release itself is faulty, use the documented reverse swap only after preserving evidence.
5. For WCF or uncertain hosting applicability, do not trial the setting as a production experiment; escalate with the evidence package.

7. Likely Root Cause Patterns¶

• A normal swap-preparation restart is mistaken for a later production incident because slot identity was not recorded.
• Former production instances recycle after becoming staging, while responders attribute those staging events to the active production slot.
• A direct app-setting or deployment change creates a recycle boundary adjacent to the swap.
• An app crash or Auto-Heal action replaces the worker, with no discriminating evidence for hostname bindings.
• The conditional hostname-binding mechanism remains plausible, but customer-visible evidence cannot identify the underlying trigger; the correct outcome is INCONCLUSIVE.

8. Immediate Mitigations¶

• Preserve the evidence timeline before restarting, swapping again, or changing settings.
• If release health is unacceptable, perform the documented reverse swap to the last known-good site.
• For applicable native Windows non-WCF apps, plan the all-slot setting change in nonproduction first; do not patch only production.
• If crashes or Auto-Heal are evidenced, follow the Windows IIS/Kudu diagnostics path rather than attributing the event to bindings.
• Engage Azure support when host-level discrimination is required and customer-visible telemetry is insufficient.
• Never induce production storage failover, detach storage, or trigger a destructive platform event to reproduce this mechanism.

9. Prevention¶

• Capture slot name, deployment ID, PID, process start time, approved instance marker, and swap correlation ID in every release evidence bundle.
• Manage WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG consistently across all slots when the documented mitigation is applicable.
• Add an explicit WCF/hosting-model applicability check to the deployment-slot runbook.
• Separate swap-operation events, configuration changes, deployments, platform replacements, and app crashes in dashboards and incident timelines.
• Preserve a rollback manifest showing the previous value and slot-setting state for every slot.
• Use INCONCLUSIVE rather than inventing a platform event when discriminating telemetry is absent.

See Also¶

• Windows Slot-Swap First-Request Latency
• Deployment Slots Operations
• Windows IIS web.config Startup Failures
• Windows Kudu and Diagnostic Tools
• Linux Slot Swap Restart / Config Drift / Warm-up Race
• Slot Swap Failed During Warm-up

Sources¶

• Set up staging environments in Azure App Service
• App Service environment variables and app settings
• AppServiceHTTPLogs table reference
• AppServicePlatformLogs table reference
• Microsoft.Web/sites Azure Monitor table catalog