Reachability rationale

We classify host+path reachability using a passive, best‑effort heuristic derived from Kubernetes resources observed by informers. We do not send active probes.

Why passive only

• No extra traffic or side effects in clusters
• Simpler operations; no probe scheduling or timeouts
• Predictable resource usage

Heuristic summary

• If Endpoints or EndpointSlice state for the backend service has Total > 0 → reachable
• If Endpoints or EndpointSlice state exists but Total == 0 → unreachable
• Otherwise → unknown

Implications

• Results can lag behind reality; informer latency applies
• Unknown does not mean down; it means insufficient evidence
• Active probes could improve certainty but add cost and complexity

References

• Code: internal/reachability/reachability.go
• Spec: DOC-004; DECISION-002 (trade‑off rationale)