Use both active and passive health checks together. Active probes detect hosts that have stopped responding or return unexpected status codes, while passive checks watch real traffic and reveal failures under live load. Combining them reduces blind spots, limits unnecessary traffic overhead, and lets the load balancer stop sending requests to broken instances before user impact spreads.
How active and passive checks work together in microservice traffic control
Health checks solve two different failure-detection problems. Active checks are synthetic probes that confirm an instance still responds correctly to the expected endpoint, status code, or dependency test. Passive checks observe live request outcomes and catch failures that only appear under real traffic, such as timeouts, elevated error rates, or partial degradation. The useful design choice is not active versus passive, but how to combine them so routing decisions reflect both baseline liveness and real service behaviour.
In practice, active checks are the faster way to detect that an instance is dead, wedged, or clearly misconfigured. Passive checks are better at surfacing failures that look healthy in a probe but fail once concurrency, payload shape, downstream calls, or resource pressure increases. That distinction matters in distributed systems because a service can be reachable and still be unsafe to route to.
Teams should treat the health signal as part of the routing contract, not just a monitoring feature. If the load balancer, gateway, or service mesh consumes the signal too slowly, unhealthy instances keep receiving traffic long after they should have been drained. If the signal is too aggressive, healthy instances may be ejected during brief blips, which can create avoidable churn and capacity loss.
What good health check design avoids
The common failure mode is relying on a single probe that only proves one narrow condition. An active probe that returns 200 can miss a database outage, thread exhaustion, queue saturation, or dependency failure. A passive-only design can be too slow to protect users because it waits for real traffic to fail before the balancer reacts. Good design uses both to reduce blind spots without turning health evaluation into a traffic tax.
Health checks also need to match the service’s actual failure modes. A deep check that walks every dependency may be accurate, but it can become expensive, noisy, or self-defeating if it adds load to already stressed components. A shallow probe may be cheap, but it can falsely reassure the scheduler. The right balance is usually a lightweight liveness check for basic responsiveness plus a separate readiness or passive signal for route eligibility.
When teams define these signals well, they create clearer operational behaviour during deploys, autoscaling, rolling restarts, and partial outages. When they define them poorly, the system can oscillate between sending traffic to sick instances and ejecting instances that could have recovered without intervention.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Continuous monitoring supports detecting unhealthy or failing service behaviour quickly. |
| Recommendation — Monitor service and dependency signals continuously to detect routing-impacting failures early. | ||
| CIS Controls v8 | 8 — Audit Log Management | Log and event signals help confirm when live traffic shows degradation that probes miss. |
| 12 — Network Infrastructure Management | Load balancer and routing infrastructure must enforce health-state based traffic decisions. | |
| Recommendation — Collect and review service and gateway logs to identify live-failure patterns that health probes miss. Configure routing layers to stop sending requests to instances that fail health criteria. | ||
Practitioner Guidance
What to prioritise: Separate the question “is the instance alive?” from “should it receive traffic?” Use the first for restart and orchestration decisions, and the second for routing decisions so temporary or partial failures do not contaminate every control plane decision.
What to verify: Confirm that the router or mesh actually consumes the health signal fast enough to stop new requests before user-visible impact spreads. Also verify that passive feedback is based on meaningful live-signal thresholds, not just raw request counts, so one noisy client cannot evict healthy capacity.
Common mistake: Teams often make the probe too deep and too frequent, then wonder why monitoring itself becomes part of the outage. The better pattern is to keep the active probe cheap and predictable, then let passive checks provide the under-load evidence that synthetic probes cannot see.
Practitioner takeaway: The goal is not maximum health-check coverage, it is trustworthy routing with minimal false confidence, so health signals should be cheap, fast, and aligned to the actual failure mode you want the balancer to avoid.
Related resources from NHI Mgmt Group
- How should security teams implement AI model routing in AWS environments with mixed traffic patterns?
- How should privacy and data governance teams implement automated policy management across fragmented data environments?
- How should data teams implement data observability when pipeline volumes and source diversity make manual data quality checks too slow?
- How should security teams implement a central execution boundary for LLM traffic in production environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
