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.
Sınırları bil
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.
Kaynaklar ve ileri okuma
CoreTrailKit tarafından hazırlanan teknik yayın.
Bütün yazıları keşfet