In brief
A 502 or 503 is a symptom, not a root cause. Separate application startup, worker health, deployment, dependency, and upstream routing evidence before changing production.
Key takeaways
- Test the default App Service hostname before investigating an upstream gateway.
- Correlate the first failure with deployment, restart, scaling, and configuration timestamps.
- Collect runtime evidence before restarting whenever the incident allows it.
- Verify representative application transactions after service recovery.
Define the failure boundary first
Start by confirming whether the failure affects every request, one route, one region, or only traffic that passes through a custom domain, Front Door, or Application Gateway. Test the default azurewebsites.net hostname from an approved network. If the default hostname works while the public path fails, focus on DNS, TLS, health probes, host headers, and upstream routing instead of changing the application.
Record the exact status code, response body, UTC timestamp, affected hostname, correlation identifier, and client location. Check Azure Service Health and Resource Health, but do not assume a platform incident simply because the application is unavailable. Most investigations become faster when application behavior and platform health are evaluated separately.
Correlate the failure with recent changes
Compare the first failed request with deployment history, configuration changes, slot swaps, scale operations, certificate updates, networking changes, and restarts. A successful deployment only confirms that deployment completed; it does not prove that the new process started, remained running, or became ready to accept traffic.
For Linux and custom-container apps, confirm the startup command, exposed port, container logs, image availability, and startup time. For Windows apps, review event logs, application logs, failed request tracing when appropriate, and runtime configuration. In both cases, compare application settings with the last known working version and look for missing secrets or connection information.
- Review deployment logs separately from runtime logs.
- Check CPU, memory, requests, response time, restarts, and HTTP queue behavior.
- Inspect Application Insights exceptions and dependency failures around the same timestamp.
- Confirm health-check paths do not require authentication or unavailable dependencies.
Choose the smallest reversible recovery action
Use the evidence to rank likely causes before taking action. Rolling back a newly deployed build is more informative than changing several unrelated settings. Restarting may restore an unhealthy worker, but it can also clear useful evidence and leave the actual defect unresolved. Capture logs first unless the business impact requires immediate mitigation.
If only one instance is unhealthy, compare it with healthy instances before replacing it. If every instance fails after a release, consider a slot rollback or redeployment of the last known working artifact. If the app works directly but fails behind a gateway, preserve the application and correct the routing, probe, TLS, or hostname mismatch at the upstream layer.
Verify recovery and prevent recurrence
A green overview page is not enough. Test a representative user transaction, confirm dependency calls, watch error rate and latency, and verify every application instance. Continue monitoring beyond the first successful request so a temporary restart recovery is not mistaken for a permanent fix.
Document the failure boundary, decisive evidence, root cause, mitigation, and preventive control. Useful follow-up actions can include deployment health gates, startup telemetry, synthetic availability tests, alerting on restart patterns, safer slot swaps, and configuration validation before release.