LEARN. PRACTICE. GROW.Concept and mechanism
A TCP check shows that a connection can open; it does not automatically execute a business query. An HTTP check can also be too superficial if it observes only a static page. Define representative inexpensive criteria, avoiding monitoring that worsens overload. Passive health checking uses actual traffic results; active mechanisms perform their own periodic observations. In NGINX, max_fails and fail_timeout in a multi-server group participate in counting and temporary exclusion under configured conditions. Do not confuse them with a request total deadline or every active-check capability, whose availability depends on edition and implementation.
Guided application
In Kubernetes, readiness governs readiness for regular traffic; liveness can trigger restart. Failing liveness because a shared dependency is unavailable can restart many instances without fixing the cause. Startup probes allow normal initialization before liveness and readiness. Criteria and tolerances should reflect the observed service. Consequences when every target fails also vary: AWS ALB documents fail-open when all targets are unhealthy across all enabled zones. Do not assume total absence of traffic from the label alone. In an exercise, contain the backend failing queries, establish remaining capacity, and correct the check that missed that inability.
An open port does not prove a working business query; ALB unhealthy does not guarantee isolation when every target fails.
Common pitfalls
A check as proof of every dependency; liveness as readiness; external failure as a universal restart; status as universal semantics.
Related topics: Routing and TLS boundaries · Algorithms, affinity, and state · Retries, limits, and client origin
Connect each check to a concrete hypothesis and a known reaction.
Reference: Kubernetes startup, liveness and readiness probes · DR load balancing 2026-09; selected NGINX, HAProxy 3.2, Kubernetes and AWS ALB behavior