Cloudflare Load Balancing origin pools explained

What pools are for

A Cloudflare load balancer sits in front of your origins and decides which one serves a given request. The core unit is the pool: a named group of origins, each identified by an address (an IP, a hostname, or a Cloudflare-managed address). Pools group the servers you would fail between, so an "EU pool" holds the Frankfurt and Dublin origins and a "US pool" holds the two United States origins, or "primary" and "fallback" hold the active and disaster-recovery sites.

Building in pools instead of scattering origins directly on the load balancer gives you three properties:

• Failover groups: when a whole region degrades, the load balancer fails over the traffic to another pool.
• Health threshold: a pool is considered healthy when at least a set minimum of its origins pass the health checks. Raise the minimum to make the pool more conservative, or keep it low enough that one bad server does not take the region out.
• Clean fallback: you must assign a fallback pool, the last-resort destination when every primary pool is unhealthy.

A pool can hold a single origin, and for many sites that is the right shape. The pool is still useful because the monitor and the steering live at the pool level, so a one-server pool plus a monitor gives you a load balancer that knows when to stop serving.

How monitors drive health

Each pool is associated with a monitor: a request the Cloudflare network sends on an interval. When it passes, the origin and pool are healthy; when it fails repeatedly, they are unhealthy. Practical choices: HTTP(S) (hit a path, expect a status code, checks the actual application), TCP (a port accepts connections, useful for non-HTTP services), or ICMP ping (the host is reachable, weakest signal).

Choose a path that reflects real health. A monitor that gets 200 on /healthz but 503s on / tells you little. Because Cloudflare probes from multiple data centers, you also see reachability from the edges your users actually use.

Steering and traffic distribution

Steering controls how traffic distributes across healthy origins within a pool:

Above the pool level, geo steering routes regions to their pool ("West Europe to Europe, the Americas to the US"), and pools are ordered so traffic prefers the first healthy one. The request arrives, the load balancer picks a pool within the rules, then steering picks an origin within the pool.

The sequence when an origin fails

1. The monitor marks the origin unhealthy, after a failure count, not a single probe.
2. New requests stop going to that origin.
3. Traffic routes to the next healthy origin in the pool.
4. When the pool drops below its health threshold, traffic fails over to the next pool in order; all pools unhealthy goes to the fallback pool.
5. You act on notifications: pause or remove the failing origin, re-enable it when the monitor flips back healthy.

The classic 522 and 524 edge errors are exactly what a misconfigured pool produces: traffic lands on a dead or overloaded origin while the fallback path never gets a chance. The origin refused and timeout articles cover the two origin failure modes a load balancer is meant to catch.

Set up

1. Open Traffic > Load Balancing and click Create load balancer.
2. Name it and give it a hostname (lb.example.com).
3. Create a pool and origins, attach a monitor with the right check type and interval.
4. Set the health threshold, choose steering, assign the fallback pool.
5. Point the DNS record for the hostname at the load balancer.
6. Publish a small test percentage on a staging hostname before production.

Pool and origin health over time, plus failover events, sit in the analytics. Keep notifications on real thresholds (pool flips, origins unhealthy) rather than silent failures.