About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Direct answer: A load balancer removes pool members when a health probe fails its configured test. The application can still work for direct testers while new production traffic is no longer routed to it because the probe checks the wrong path, expects the wrong status code, cannot complete TLS, or runs a “deep” test that fails under load. Steady-state design requires aligning probes with what must be true for a user transaction, not with the easiest HTTP 200 on /.
This article covers health-check behaviour in live operations, not virtual-IP recovery or pool rebuild after site loss.
Why it matters
False negatives produce partial or total outages that bypass application logs: requests never arrive. Operators restart app pools, blame databases, or fail over sites while the root cause is a probe pointing at a retired URL or http:// when the site redirects to https:// on 301 (interpreted as failure).
Hosted multi-tier stacks add probe source addresses, host headers, and certificate name constraints. A probe without SNI may hit a default vhost that returns 404 while the real site answers correctly with the proper Host header.
How it works
Different load distribution products have different contracts. Do not transfer one product's status-code or failure-threshold rules to another.
For Azure Load Balancer HTTP/HTTPS probes, HTTP 200 indicates success. An explicit non-200 response marks the probe down immediately; the consecutive timeout threshold is not a grace period for non-200 responses. TCP resets and missing responses have their own documented failure handling. Existing TCP flows can behave differently from new flows: when one backend is unhealthy, established TCP connections can continue; when all are unhealthy, Standard Load Balancer permits established TCP flows to continue under the documented condition that the pool has more than one instance. Check the deployed SKU and state rather than assuming every session ends.
NGINX active HTTP health checks use ngx_http_upstream_hc_module, which requires a commercial subscription. Open-source upstream passive checks use observed request failures with settings such as max_fails and fail_timeout; these are not the same active health_check feature.
| Problem | What to check | Design direction |
|---|---|---|
| Probe path removed | Deployed route and documented expected status | Keep a dedicated, stable, minimal health route |
| Plain HTTP meets an HTTPS redirect | Selected protocol and actual response | Use the product's supported protocol and endpoint contract |
| Probe reaches a default virtual host | Documented Host/SNI behaviour of that exact product | Use a compatible listener; configure Host/SNI only if supported |
| Database check fails | Whether the dependency is essential for serving this route | Choose readiness gating deliberately; separate diagnostics from routing |
| Application requires client certificates | Probe's supported authentication and source controls | Use a supported authenticated probe or restricted health-only endpoint; never bypass authentication on business routes |
Liveness asks whether the process or listener is alive. Readiness asks whether this instance should receive new traffic. A critical dependency failure may correctly fail readiness; an optional dependency should not automatically evict every instance. Decide per application, and keep deeper synthetic transactions for diagnosis and end-to-end checks. A shallow heartbeat alone does not establish business readiness.
What to choose and why
Define a health endpoint contract owned by the application team: path, expected code, authentication, permitted probe sources and dependencies. If the selected probe cannot authenticate, expose only a dedicated minimal health endpoint restricted to the appropriate probe source/path, with no customer data, credentials or diagnostic details. Keep business routes under their normal authentication. Alternatively use a supported authenticated probe design. Document and test these controls together with the firewall rules.
Match supported probe intervals and timeout behaviour to startup readiness. For Azure HTTP probes, an explicit non-200 remains an immediate failure regardless of the timeout threshold; plan startup and traffic introduction around that contract.
After certificate or redirect changes, revalidate probes before cutover—common regression when HSTS or HTTP→HTTPS rules tighten.
Log probe failures separately from user access logs where the platform allows, to shorten mean time to diagnosis.
Risks and limits
Some platforms conflate out-of-service admin drain with probe failure; know how to distinguish manual drain.
UDP/RDP farms may need different probe types than HTTP LOB apps. This draft does not validate a specific cloud SKU (untested).
Sources
Primary sources checked 14 November 2026. Procedures remain source-researched, not lab validated.
- Azure Load Balancer health probes | Microsoft Learn
- NGINX ngx_http_upstream_hc_module (commercial active checks)
- Module ngx_http_upstream_module
- Configure certificate authentication in ASP.NET Core | Microsoft Learn
Related future topics
Firewall port verification; mutual TLS at tiers. Cloud hosting — related only.
Learning notes
- Users can reach an app directly while the LB starves it of traffic.
- Redirects and TLS mismatches are frequent probe regressions.
- Liveness and readiness answer different questions; only appropriate critical dependencies should gate routing.
- Host/SNI controls and status-code rules depend on the selected product; Azure HTTP probes require 200.
- Steady-state probe design is not the same problem as VIP recovery after disaster.
This article was originally published on .