In brief
Backend health is the fastest boundary check for Application Gateway incidents. Interpret the status and probe message before changing listeners, routing rules, or the backend application.
Key takeaways
- Record the exact backend health message for each pool member and setting.
- Test connectivity and name resolution from the gateway's network path.
- Match probe protocol, port, path, hostname, timeout, and accepted status codes.
- Validate the backend TLS certificate chain and hostname for HTTPS probes.
Read backend health before changing configuration
Open the backend health view and identify the exact pool member, backend setting, probe, and error message. Healthy means the latest probes met the configured conditions. Unhealthy means the target responded incorrectly or could not be reached. Unknown commonly indicates that the gateway cannot determine health because of name resolution, routing, connectivity, configuration, or permission problems.
Check whether every member is affected or only one address, zone, or backend setting. If one target fails while peers remain healthy, compare the target configuration and application state. If every target fails at the same time, prioritize shared dependencies such as DNS, routes, NSGs, firewall rules, backend settings, and the probe definition.
Validate the network path
Confirm that the gateway subnet can route to the backend address and port. Review user-defined routes, NSGs, firewalls, peering, private endpoint design, and return paths. When the pool uses a fully qualified domain name, verify that the gateway's DNS configuration resolves the intended address and that changes have propagated.
A successful test from a laptop does not prove reachability from Application Gateway. Test from a resource that shares the relevant network path when permitted. Also confirm that the backend is listening on the configured protocol and port and that no intermediate control blocks the source or return traffic.
Review probe and TLS behavior
A custom probe should use a lightweight path that reflects whether the instance can accept traffic. Match its protocol, port, path, hostname, timeout, interval, and healthy status-code range to the application. Avoid a health endpoint that performs expensive work or depends on every downstream service unless that behavior is intentional.
For HTTPS backends, verify the certificate chain, expiration, hostname, and trust relationship expected by the backend setting. A mismatch between the host header, server name, certificate subject, and backend address can produce health failures even when the application responds successfully in a different test.
- Call the probe URL directly from an approved network and record the response.
- Confirm redirects and authentication do not make the health path fail.
- Review the complete server certificate chain and certificate validity dates.
- Check whether the backend expects a specific host header or server name.
Recover and verify end-to-end
Correct the smallest confirmed mismatch and wait for multiple probe cycles. Do not broaden NSG rules or disable certificate validation merely to make the status green. If the backend application is actually unhealthy, resolve that failure directly and allow the gateway to return it to rotation after the probe succeeds.
Verify the public listener, routing rule, backend selection, representative application request, logs, and monitoring after backend health recovers. Record whether the incident was caused by application readiness, routing, DNS, security controls, or TLS so the preventive change is applied at the correct layer.