Server and pool health
5 min read
As discussed before, a monitor issues health checks periodically to evaluate the health of a each server within a pool.
These health checks are requests issued by a monitor at regular interval and — depending on the monitor settings — return a pass or fail value to make sure an origin is still able to receive traffic.
Each health monitor request is trying to answer two questions:
- Is the server offline?: Does the server respond to the health monitor request at all? If so, does it respond quickly enough (as specified in the monitor’s Timeout field)?
- Is the server working as expected?: Does the server respond with the expected HTTP response codes? Does it include specific information in the response body?
If the answer to either of these questions is “No”, then the server fails the health monitor request.
Based on the characteristics of your server pools, you have several customization options that affect how and whether a server is considered unhealthy.
The Health Threshold is the number of healthy origins for the pool as a whole to be considered Healthy and receive traffic based on pool order in a load balancer. Increasing this number makes the pool more reliable, but also more likely to become unhealthy.
Health monitor regions
For each option selected in a pool’s Health Monitor Regions, Cloudflare sends health monitor requests from three separate data centers in that region.
If the majority of data centers for that region pass the health monitor requests, that region is considered healthy. If the majority of regions is healthy, then the origin itself will be considered healthy.
All Data Centers (Enterprise only)
Health monitor probes are sent from every single data center in Cloudflare’s network to the origins within the associated pool. This allows probes to hit each origin during intervals set by the customer.
Three health monitor probes per region are sent to each origin in the associated pool. There are a total of 13 regions, resulting in 39 probes.
Three health monitor probes are sent from each specified region within the pool configuration.
When you , there are several configuration settings you can adjust based on the characteristics of the attached pools:
302) or as a range (for example, entering
2xx would cover all response codes in the
302 code as unhealthy, the health monitor request follows redirects to the final endpoint.
You also need to decide which of the associated pools in a load balancer should be the fallback pool.
This pool is meant to be the pool of last resort, meaning that its health is not taken into account when directing traffic.
Fallback pools are important because traffic still might be coming to your load balancer even when all the pools are unreachable (disabled or unhealthy). Your load balancer needs somewhere to route this traffic, so it will send it to the fallback pool.