Cloudflare Docs
Learning Paths
Cloudflare Docs
Learning Paths
GitHub icon
Visit Learning Paths on GitHub
Set theme to dark (⇧+D)
  1. Learning paths
  2. Planning your load balancer
  3. Server and pool health

Server and pool health

  4 min read

As discussed before, a monitor issues health checks periodically to evaluate the health of a each server within a pool.


Each health check is trying to answer two questions:

  1. Is the server offline?: Does the server respond to the health check at all? If so, does it respond quickly enough (as specified in the monitor’s Timeout field)?
  2. 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 check.

​​ Customizations

Based on the characteristics of your server pools, you have several customization options that affect how and whether a server is considered unhealthy.

​​ Pool-level settings

​​ Health threshold

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 check regions

For each option selected in a pool’s Health Check Regions, Cloudflare sends health checks from three separate data centers in that region.

Health checks come from three data centers within each selected region.

If the majority of data centers for that region pass the health checks, that region is considered healthy. If the majority of regions is healthy, then the origin itself will be considered healthy.

​​ Configurations

All Data Centers (Enterprise only)

Health check 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.

All Regions

Three health check probes per region are sent to each origin in the associated pool. There are a total of 13 regions, resulting in 39 probes.

Regional

Three health check probes are sent from each specified region within the pool configuration.

​​ Monitor-level settings

When you create a monitor, there are several configuration settings you can adjust based on the characteristics of the attached pools:

Basic settings
  • Type: The protocol to use for health checks
    • Non-enterprise customers: Choose HTTP, HTTPS, or TCP.
    • Enterprise customers: Choose HTTP, HTTPS, TCP, UDP ICMP, ICMP Ping, or SMTP.
  • Path: The endpoint path to run health checks against
  • Port: The destination port for health checks
Advanced settings
  • Interval:
    • By increasing the default, you can improve failover time, but you may also increase load on your servers.
    • Minimum time in seconds is 60 (Pro), 15 (Business), and 10 (Enterprise).
  • Timeout and Retries:
    • The health check will return unhealthy if it exceeds the duration specified in Timeout (and exceeds this duration more times than the specified number of Retries).
  • Expected Code(s): The expected HTTP response codes listed individually (200, 302) or as a range (for example, entering 2xx would cover all response codes in the 200 range).
  • Response Body:
    • Looks for a case-insensitive substring in the response body.
    • Make sure that the value is relatively static and within the first 100 MB of the HTML page.
  • Simulate Zone:
    • Pushes a request from Cloudflare Health Monitors through the Cloudflare stack as if it were a real visitor request to help analyze behavior or validate a configuration.
    • Ensures health checks are compatible with features like authenticated origin pulls and Argo Smart Routing.
  • Follow Redirects:
    • Instead of reporting a 301 or 302 code as unhealthy, the health check follows redirects to the final endpoint.
  • Configure Request Header(s):
    • Useful if your servers are expecting specific incoming headers.
  • Header:
    • The HTTP request headers to send in the health check. It is recommended that you set a Host header by default. The User-Agent header cannot be overridden. This parameter is only valid for HTTP and HTTPS monitors.

​​ Fallback pool

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.




Unit 4 of 6

Previous
Next