0.29.7

docs/VHOSTS.md

@@ -44,6 +44,23 @@ The main vhost `source` may define `error_fallback`, and each Custom location ma
 
 Configured upstream/Web Server failures are intercepted before final response/cache publication. The original request method, URI/query and context are internally dispatched to the target, which then follows normal vhost/location processing. Validation rejects fallback cycles and runtime dispatch is depth-limited. See [V0.29.1_IMPLEMENTATION.md](V0.29.1_IMPLEMENTATION.md) for body replay bounds and an Nginx-style static -> app -> redirector example.
 
+## Per-backend health monitoring (0.29.7)
+
+Each backend has an independent `health_check_enabled` switch (default `true`).
+Setting it to `false` excludes that member from both active health probes and
+passive health ejection, **without** disabling the member for a named location.
+This is useful for an internal 404 handler configured with `pool_eligible: false`
+and a location pinned through `backend_id`: the 404 handler never receives
+ordinary balanced traffic and does not need health monitoring.
+
+A backend may also define `health_check` with the same fields as
+`load_balancing.health_check` to use its own TCP/HTTP/off probe policy, timing,
+path, Host and status ranges. Omitting it inherits the vhost policy. A custom
+HTTP health check without `host` inherits the vhost Host default even when the
+vhost's main health check is TCP. When monitoring is disabled, the backend is
+assumed available; connection errors during real requests are still counted and
+logged, so monitoring off is not a guarantee of backend reachability.
+
 ## Frontend selection and private IP isolation
 
 `frontend.hosts` is a normalized hostname-pattern list. Exact hostnames and a single