Load Balancing in Cloudflare spreads requests across several origin servers and automatically drops from rotation those that stop responding. The service helps when a site runs on two or more servers — for example, in different data centers in Germany and the US — and needs to survive one of them failing without manual action.
Three entities form the base: origins — the actual servers with addresses, pools — groups of origins with shared check logic, and the load balancer itself — a rule that ties a domain to pools and sets the failover order.
How to set up a Load Balancer: steps
Setup happens under Traffic → Load Balancing.
- Create a Monitor — an availability check rule with a path and expected response code.
- Create a Pool and add origin servers to it with weights.
- Attach the created Monitor to the pool.
- Create a Load Balancer, specify the domain, the primary pool, and a backup one.
- Choose the traffic steering method and save.
Pools, origins, and health checks: parameters
The table shows the key parameters that determine how fast the service notices a failure.
| Parameter | Example value | Effect |
|---|---|---|
| Check interval | 60 seconds | How often the origin is polled |
| Retries | 2 attempts | Failures before exclusion |
| Expected codes | 200 | What counts as success |
| Timeout | 5 seconds | Response wait threshold |
Steering methods and failover scenarios
The steering method is set at the load balancer level and decides exactly where a request goes when several origins are alive.
steering_policy: "geo" | "dynamic_latency" | "random" | "off"- Geo steering — a request goes to the data center closest to the user, useful with servers in Germany, the US, and France at the same time.
- Dynamic latency steering — picks the origin with the lowest measured response delay.
- Failover without active steering — all traffic goes to the primary pool, the backup switches on only on a complete failure.
Load Balancing and DNS: how they combine
A Load Balancer replaces a regular A record — instead of a static IP, the domain points to the balancer, which then decides which origin responds. Basic domain records are still configured under DNS in Cloudflare, but the record for the balanced name itself is created automatically when the Load Balancer is saved.
If the backup origin sits behind NAT without a public IP, it makes sense to connect it through Cloudflare Tunnel — that way the balancer gets access without opening ports outward.
How to test failover and check the logs
Disable the primary origin during a test and confirm the domain keeps responding through the backup.
curl -I https://example.com/healthThe history of origin states and switches is available in Traffic → Load Balancing → Monitors, showing the time of each event and the check failure reason.
Checklist before launching the balancer
- The Monitor checks a real sign of health, not just an open port.
- The pool has a backup origin with a sensible weight.
- The steering method matches the geography of servers and users.
- Failover was tested manually by disabling the primary origin.
- Notifications about pool state changes are set up by email or webhook.