01
Inspect the response before any redirect
App Service documents that Health check does not follow 302 redirects. A browser can therefore show a successful final page while the probe receives a non-success first response. Compare the exact configured path rather than testing the site homepage.
The local fixture returned 302 from /health-redirect and 200 from /health-ready. A normal redirect-following client saw 200 for the first URL; a non-following client correctly exposed its 302. Both observations were true for different request behavior.
# curl does not follow redirects unless requested with -L.
curl --silent --show-error --output /dev/null \
--write-out '%{http_code}\n' https://YOUR_APP/health02
Trace the redirect to its owner
Inspect the response headers and application routing. Login middleware, path canonicalization, or HTTP-to-HTTPS handling can redirect a route that seemed like a health endpoint. Determine which component produced the first response before changing health thresholds.
Keep authentication and transport security intact. Do not fix a health check by disabling them across the app. Configure the intended health path and its permitted probe behavior using the platform and application guidance for that deployment.
curl --silent --show-error --dump-header - --output /dev/null \
https://YOUR_APP/health03
Return a meaningful result directly
The health endpoint should report the contract the application requires for serving traffic. A direct success should indicate that chosen contract is met; a deliberately unavailable dependency can warrant a non-success response rather than a redirect to a nicer page.
This framework-independent example illustrates the status decision only. The application must connect it to its actual health criteria and HTTP routing. It is not a substitute for checking the dependencies that matter to its traffic.
def health_result(required_dependencies_ready):
if required_dependencies_ready:
return 200, b"ready"
return 503, b"unavailable"04
Verify both the direct endpoint and platform evidence
Repeat the no-follow request after the route correction, then review App Service’s actual health observations over its configured evaluation window. A single local request cannot establish that every instance or platform probe is healthy.
Our corrected fixture path returned 200 without a redirect. That validates the HTTP contract difference only. We did not simulate platform timing, authenticated probe headers, instance replacement, or scale-out behavior.
05
Keep application reachability as a separate layer
If the no-follow request times out or cannot reach the process, return to application startup, listener configuration, and the relevant network path. If it returns a genuine unhealthy result, inspect the health criteria instead of hiding them behind a constant success.
Preserve the configured path, first status, redirect destination where relevant, and platform outcome. Those details explain why a browser check differed from the probe and make a later routing change easier to diagnose.
Know the limits
Validated with a local HTTP fixture and Microsoft’s documented App Service contract. A redirect-following request reached 200, while a non-following request saw 302; the direct ready endpoint returned 200. App Service probe scheduling, instance exclusion, and the cloud control plane were not tested.
Sources & further reading
A technical publication by CoreTrailKit.
Browse all articles