Backend health is the result of a configured test
A load balancer health check evaluates a particular backend using a defined protocol, port and response expectation. A failed result does not describe every function of that application. A web page can respond locally while the configured probe cannot reach the correct listener or receive the expected response.
Google documents different health-check and firewall requirements depending on the load balancer and traffic type. Identify the actual product configuration before copying source ranges or rules. A generic 'allow health checks' change can be both too broad and incomplete if it targets the wrong instances or protocol.
Prepare an explicit health contract
- Record the load balancer type, backend association, health-check protocol, port and endpoint behavior. Assign ownership of that endpoint to the application team.
- Review required probe connectivity for the selected architecture. Keep management traffic, user traffic and probe traffic distinct in the network design.
- Measure application startup and normal response behavior. Rehearse healthy, unready and failed application conditions in a non-production backend.
For beginners, accepting a TCP connection is a different contract from returning an application-specific HTTP success. Choose the health test around the failure that routing must detect, rather than making every probe report success to remove an alert.
Illustrative incident: the listener port changes during release
A candidate backend starts its application on a new port while the health check still targets the old one. Existing backends remain healthy, but new capacity is rejected. This is an illustrative scenario. Relaxing the response matcher cannot repair a connection to a port where the application is not listening.
Compare the actual endpoint with the configured probe
Review backend health evidence alongside application listener and access logs. Determine whether the probe reaches the guest or service before changing response semantics. Inspect firewall targeting as well as source scope; a correct source range on a rule that does not apply to the backend is not an effective permission.
| Observation | Evidence | Investigation boundary |
|---|---|---|
| No connection reaches the listener | Probe port and applicable network path | Connectivity |
| Request arrives, response is rejected | Protocol, path and expected response | Application contract |
| Only new backends fail | Candidate listener and configuration diff | Release mismatch |
| Health is green, real requests fail | User route and dependency behavior | Incomplete acceptance test |
Use current provider guidance for the actual architecture's probe sources and connectivity. Do not open every port or public source simply to determine whether the service can ever become healthy.
Correct the mismatch without concealing readiness
For the illustrative port change, coordinate the listener and health-check definition in the release configuration. Preserve the last accepted backend and probe settings. If the evidence instead shows a firewall-targeting problem, have the network owner approve the narrow correction with its intended resource scope.
Observe the candidate becoming healthy, then perform a real user operation through the load balancer. Rehearse an intentionally failed application condition and confirm the check detects it. Test a rolling replacement so acceptance includes the transition, not only a stable endpoint after manual repair.
Reliability and the backend-health SOP
Measure successful user requests, healthy capacity and startup duration separately. An illustrative internal release gate could require one candidate to pass both probe and user-operation checks before old capacity is reduced. This is an acceptance rule, not a load-balancing SLA or a universal zero-downtime promise.
The SOP should retain product type, backend, probe definition, applicable firewall rule, release comparison and reversal trigger. Escalate changes affecting all backend groups or shared network policy. Review the health contract whenever the application framework, port or dependency behavior changes; a previously valid probe is not automatically valid for every later release.
Clouvenix can scope related engineering support around documented ownership, change approval and acceptance evidence.
Technical reference
Google Cloud: use health checks. References reviewed 19 October 2026; confirm the configuration and supported behavior for your deployed environment.