Azure App Service Health Check: design an endpoint that detects real failure

Choose what healthy means for this application

App Service Health Check periodically requests a configured path on the application's instances. It uses successful HTTP status codes to determine whether an instance can remain in the serving pool. That makes the endpoint an operational contract: it should represent the application's ability to accept work, not merely prove that the process can return a string.

Start by listing the dependencies that must work for a normal request. A database might be essential, while an optional analytics service can fail without preventing the application from serving users. Health checks should reflect that distinction. Checking every remote dependency on every probe can turn a minor upstream incident into an unnecessary removal of otherwise useful application instances.

Keep the response fast, bounded and safe

Use short, bounded dependency checks and avoid expensive queries or writes. The path should return a successful response when the instance is ready and a failure response when it cannot serve its essential workload. Do not redirect the probe to a sign-in page or rely on a long-running operation that consumes substantial application capacity.

App Service's built-in authentication features integrate with Health Check. If the application implements its own authentication system, the configured health path must be reachable as documented for the probe. Review the platform's supported validation guidance if additional protection is required. Never make a health response a public dump of environment variables, connection strings or token details.

Validate the platform and application together

1. Configure a stable health path and the intended instance-health thresholds.
2. Verify that the path returns a 2xx response when the instance is ready.
3. Confirm custom authentication and redirect behavior do not interfere with the probe.
4. Rehearse a controlled dependency failure in a nonproduction environment.
5. Inspect per-instance health and real request outcomes during recovery.

App Service uses configurable behavior to determine when an instance is unhealthy and how much of the serving pool may be excluded. Review those settings against the application's instance count. A single-instance service still has a capacity and availability limitation; a health endpoint does not create another ready instance by itself.

Avoid confusing readiness with every form of liveness

A process can be running but unable to serve essential requests, or temporarily busy while still capable of recovery. Use telemetry to distinguish these states. The endpoint should answer a focused readiness question, while application metrics and traces explain why readiness failed. Include a safe release identifier in internal diagnostics so operators can correlate a health change with a deployment.

Test startup as well as a steady running state. A release that performs long initialization or depends on a network path unavailable during warm-up can fail health checks before it serves traffic. Keep migrations and heavy initialization out of repeated probe execution, and make startup behavior observable through bounded operational logs.

Use health data to guide recovery

After an incident, compare unhealthy-instance transitions with latency, database errors and deployment events. A useful health endpoint identifies when serving ability was lost; it is not the full diagnosis. Keep a repeatable runbook that describes the endpoint, essential dependencies, failure codes and the evidence required before restoring or replacing an instance.

References

• Monitor the Health of App Service Instances - — Microsoft Learn
• Set Up Staging Environments - Azure App Service — Microsoft Learn