App Service 502 and 503 errors: collect the evidence a restart would erase

A restart may restore an App Service application temporarily, but it can also erase the immediate state that explains the outage. When you see 502 or 503 responses, first establish whether failures affect all requests, a particular route or a period of elevated load. Record the first failure and any deployment or configuration change near it.

Observe the whole application path

Use the App Service diagnostics experience and available application telemetry to compare response failures, CPU, memory and request duration. The same HTTP status can accompany different causes. Slow downstream requests, exceptions, resource pressure and a failing application process should not all lead to the same change.

Check whether multiple applications share the same plan and whether their combined demand changed. A quiet frontend can still wait on a slow database or external API. Avoid concluding that the platform is healthy or unhealthy from one metric in isolation.

Capture useful diagnostics without collecting secrets

Inspect relevant application logs and exceptions for the affected time window. If deeper diagnostics are needed, use the supported App Service tools and assess what the resulting artifacts may contain. Memory dumps and detailed request logs can expose private data; keep access restricted and retain only what the investigation requires.

Compare a failing route with a minimal health path. A basic health endpoint returning 200 proves less than a representative transaction that reaches required dependencies. Both observations are useful when their limitations are recorded clearly.

Mitigate according to the evidence

A rollback can be appropriate when failures closely follow a release and the previous version is compatible with the current data schema. Scaling can provide headroom for confirmed resource pressure, but it adds cost and may leave a leak or unbounded operation unresolved. Restart and auto-heal behavior can reduce disruption while a root cause is investigated; they do not establish that the application defect is fixed.

Make one controlled change and measure the same signals again. Verify successful requests during a representative period, then inspect error rate and dependency latency rather than only process uptime. Add a follow-up action for the cause: a bounded query, a corrected connection lifetime, a timeout budget or another change supported by the evidence.

Document the difference between immediate mitigation and the durable fix. That distinction prevents a recurring outage from becoming an undocumented routine of manual restarts.