# Load Balancing # Changelog ## 2025-04-15 **Introducing Support for Orange-Clouded Origin Resolution** Newly created Cloudflare Load Balancers will resolve orange-clouded origin addresses, provided the origins belong to the same account and zone as the Load Balancer. Existing Load Balancers will continue using the current resolution method. If ownership validation fails, the new system falls back to the existing behavior and defaults to a gray-clouded (DNS-only) lookup, typically resolving to anycast addresses. ## 2025-03-13 **Update to Load Balancing analytics** Load Balancing request rates in analytics may decrease for some customers as an improvement is made to our infrastructure. This decrease in Load Balancing analytics does not indicate a decrease in HTTP requests received. ## 2025-02-20 **Zone name added to Load Balancing API responses** Load Balancing API responses for Load Balancers now include a `zone_name` property, which provides the name of the zone in the response data. ## 2025-02-10 **Fix for Cloudflare Tunnel Consistency** Fixes to improve the consistency of Cloudflare Tunnel handling within Cloudflare Load Balancers. These changes ensure more reliable and predictable routing, particularly when tunnels are involved. ## 2025-01-24 **Update to Cloudflare Tunnel Steering** Introduced changes to the resolution of proxied domains that are backed by Cloudflare Tunnels on the same zone. These changes correct how orange-clouded records are steered to Cloudflare Tunnels via Cloudflare Load Balancers. ## 2025-01-16 **Update to Pool Health Monitoring** We made changes to how we resolve and monitor proxied origins to assess pool health. Our analysis indicates no impact to customer configurations or operations. Contact customer support if you notice any unexpected behavior. ## 2024-12-20 **Load Balancing with the China Network** You can now enable load balancers to be deployed to the [China Network](/china-network/). Refer to the [documentation](/load-balancing/additional-options/load-balancing-china/) for more details. # Cloudflare Load Balancing Maximize application performance and availability Cloudflare Load Balancing distributes traffic across your endpoints, which reduces endpoint strain and latency and improves the experience for end users. *** ## Features **Load balancing and failover** Distribute traffic evenly across your healthy endpoints, automatically failing over when an endpoint is unhealthy or unresponsive. **Active monitoring** Monitor your endpoints at configurable intervals and across multiple data centers to look for specific status codes, response text, and timeouts. **Intelligent routing** Choose whether to distribute requests based on endpoint latency, a visitor's geographic region, or even a visitor's GPS coordinates. **Custom rules** Customize the behavior of your load balancer based on the characteristics of individual requests. **Analytics** Review comprehensive analytics to evaluate traffic flow, assess endpoint health status, and review changes in pools and pool health over time. *** ## Related products Actively monitor whether your origin server is online by sending specific requests at regular intervals. Get enterprise-grade authoritative DNS service with the fastest response time, unparalleled redundancy, and advanced security with built-in DDoS mitigation and DNSSEC. Route excess users to a custom-branded waiting room, helping preserve customer experience and protect origin servers from being overwhelmed with requests. *** ## More resources [Plans](https://www.cloudflare.com/plans/#overview) Compare available Cloudflare plans. [Pricing](https://dash.cloudflare.com/?to=/:account/:zone/traffic/load-balancing/) Explore pricing options for Load Balancing in the dashboard. [Reference Architecture](/reference-architecture/architectures/load-balancing/) Learn more about the structure of Cloudflare Load Balancers and their various configurations. [Learning Paths](/learning-paths/) Module-based guidance on Cloudflare product workflows. # Additional DNS records In addition to load balancing between DNS records used for IP resolution — `A`, `AAAA`, and `CNAME` records — Enterprise customers can also load balance between **MX** and **SRV** records. ## MX records To load balance between multiple mail servers: 1. Make sure you have the [required DNS records](/dns/manage-dns-records/how-to/email-records/#send-and-receive-email) for your mail servers. 2. [Create a monitor](/load-balancing/monitors/create-monitor/) with a **Type** of *SMTP*. 3. [Create a pool](/load-balancing/pools/create-pool/) with your mail servers and attach the newly created monitor. 4. [Create a load balancer](/load-balancing/load-balancers/create-load-balancer/) that includes your newly created pools. Since it will forward SMTP traffic, the load balancer should be [unproxied (DNS-only)](/load-balancing/understand-basics/proxy-modes/#dns-only-load-balancing). ## SRV records To load balance between different **SRV** records, which contain significantly more information than many other DNS records: 1. [Create your SRV records](/dns/manage-dns-records/how-to/create-dns-records/#create-dns-records). 2. [Create a monitor](/load-balancing/monitors/create-monitor/) with a **Type** of *UDP-ICMP* or *TCP*. 3. [Create a pool](/load-balancing/pools/create-pool/) with your various SRV records and attach the newly created monitor. 4. [Create a load balancer](/load-balancing/load-balancers/create-load-balancer/) that includes your newly created pools. This load balancer should be [unproxied (DNS-only)](/load-balancing/understand-basics/proxy-modes/#dns-only-load-balancing). # Cloudflare Tunnel (published applications) Cloudflare Tunnel (formerly Argo Tunnel) establishes a secure outbound connection which runs in your infrastructure to connect the applications and machines to Cloudflare. For more details on how to use Load Balancing with Cloudflare Tunnel and public hostnames, refer to [Route tunnel traffic using a load balancer](/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/public-load-balancers/). For using private IPs instead, refer to [Set up private IPs with Tunnel](/load-balancing/private-network/warp-to-tunnel/). # CNAME flattening for endpoints When a [DNS-only (gray-clouded)](/load-balancing/understand-basics/proxy-modes/) load balancer selects an endpoint whose address is a hostname (for example `origin.example.com`), Cloudflare resolves that hostname to an IP address and returns an `A`/`AAAA` record to the client. This is _CNAME flattening_, and it matches how [CNAME flattening works in Cloudflare DNS](/dns/cname-flattening/). Some use cases — such as third-party endpoints that perform their own DNS-based steering — require the load balancer to return the `CNAME` record itself instead of a resolved IP. The `flatten_cname` property on a pool endpoint lets you opt out of flattening on a per-endpoint basis. :::note This feature is only available with an Enterprise subscription. ::: ## When to use this Turn `flatten_cname` off (`flatten_cname: false`) on an endpoint when: - You want clients to receive a `CNAME` answer pointing at a third-party SaaS provider or cloud endpoint (for example `origin-b.example.com`). - The endpoint resolves to addresses that are dynamic, geo-aware, or client-aware downstream. - You are failing over between two hostname endpoints and want the client to resolve each provider's hostname directly. Leave `flatten_cname` on (`flatten_cname: true`, the default) for normal IP-based or hostname endpoints where you just want a fast `A`/`AAAA` answer. ## Where it applies `flatten_cname` only changes resolver output when all of the following are true: | Condition | Required value | | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Load balancer [proxy mode](/load-balancing/understand-basics/proxy-modes/) | DNS-only (gray-clouded). Proxied load balancers must return Cloudflare anycast IPs, so the setting is ignored. | | Endpoint address | A hostname (CNAME target). For raw IPv4/IPv6 endpoint addresses the setting has no effect. | | Load balancer hostname | Not the zone apex. `CNAME` records at a zone apex are not permitted, so the load balancer falls back to flattening at the apex. | | The selected endpoint | Steering selected this specific endpoint. Setting `flatten_cname: false` on endpoint A has no effect when steering picks endpoint B in the same pool. | If the selected endpoint has `flatten_cname: false` but any of the conditions in the preceding table is not met, the load balancer flattens the CNAME and returns `A`/`AAAA` records as if the toggle were on. ## Configure CNAME flattening `flatten_cname` is configured per endpoint inside a pool, alongside `name`, `address`, `weight`, and other endpoint fields. You can set it in the Cloudflare dashboard, the API, or Terraform. ### Dashboard In the dashboard, this setting appears as a **Flatten CNAME** toggle on each endpoint in a pool. Turn the toggle off to return the endpoint hostname as a `CNAME` record. 1. In the Cloudflare dashboard, go to the **Load Balancing** page. https://dash.cloudflare.com/?to=/:account/load-balancing 2. Select the **Pools** tab. 3. On the pool that contains the endpoint, select **Edit**. 4. In the **Endpoints** section, find the endpoint you want to change. 5. Turn **Flatten CNAME** off. 6. Select **Save**. **Flatten CNAME** is only available for endpoints whose address is a hostname. Endpoints that use an IP address cannot turn it off. ### API Use [Create Pool](/api/resources/load_balancers/subresources/pools/methods/create/) or [Edit Pool](/api/resources/load_balancers/subresources/pools/methods/edit/) and set `flatten_cname` on each endpoint in the `origins` array. `POST /accounts/{account_id}/load_balancers/pools` `flatten_cname` defaults to `true` when omitted, preserving today's behavior for existing pools and endpoints. ### Terraform Set the attribute on each endpoint inside a `cloudflare_load_balancer_pool` resource. ```hcl resource "cloudflare_load_balancer_pool" "primary" { account_id = var.account_id name = "primary-pool" origins = [ { name = "origin-a" address = "origin-a.example.com" enabled = true weight = 1 flatten_cname = false }, { name = "origin-b" address = "origin-b.example.com" enabled = true weight = 1 flatten_cname = false }, { name = "fallback-ip" address = "203.0.113.10" enabled = true weight = 1 } ] } ``` ## Verify Query the load balancer hostname with `dig`: ```sh dig lb.example.com A +short ``` - If steering selected an endpoint where `flatten_cname` is `false`, the answer section contains a `CNAME` record pointing at the endpoint address (for example, `origin-a.example.com.`). The client (or its resolver) is responsible for resolving that `CNAME` further. - If steering selected an endpoint where `flatten_cname` is `true` (or an endpoint whose address is an IP), the answer contains the resolved `A`/`AAAA` records. Because the answer depends on which endpoint steering selects, repeated `dig` queries against the same load balancer can legitimately alternate between `CNAME` and `A`/`AAAA` answers when a pool mixes hostname endpoints with `flatten_cname: false` and IP endpoints. ## Health monitors Endpoint health monitors are unaffected by this setting. Cloudflare always resolves the endpoint hostname to an IP and probes the underlying service using an uncached DNS lookup. Turning off flattening only changes what is returned to the client at DNS query time — health status continues to reflect the real backend reachability. ## Analytics Per-endpoint request counts and steering decisions remain visible in [load balancing analytics](/load-balancing/reference/load-balancing-analytics/), keyed by endpoint name. This lets you track how traffic is distributed across `CNAME`-returning endpoints. ## Limitations - Proxied (orange-clouded) load balancers: `flatten_cname` is ignored. Proxied load balancers must resolve to Cloudflare anycast IPs to deliver Cloudflare's HTTP/HTTPS proxy features. - Zone apex load balancers: `flatten_cname` is ignored because `CNAME` records are not permitted at a zone apex. - IP endpoints: `flatten_cname` has no effect — there is no `CNAME` to flatten or return. - DNS resolver caching: As with any DNS-only load balancer, downstream resolvers may cache the returned record for the TTL. Clients that ignore TTLs may continue to use a previously cached `CNAME` or `A` answer. - Plan requirement: Available to Enterprise customers on the Load Balancing add-on. ## Related - [DNS CNAME flattening](/dns/cname-flattening/) — the equivalent feature for non-load-balancer DNS records. - [Proxy modes](/load-balancing/understand-basics/proxy-modes/) — when to use DNS-only versus proxied load balancing. - [Common configurations](/load-balancing/load-balancers/common-configurations/) — patterns including active-active failover that benefit from CNAME-returning endpoints. # DNS persistence This guide explains how to achieve DNS persistence when using Cloudflare Load Balancing, similar to functionality provided by traditional DNS-based load balancers. DNS persistence ensures that subsequent DNS requests from the same local DNS server receive the same IP address. This is useful for applications that require session consistency, such as VPN connections or authentication systems. Cloudflare Load Balancing can achieve DNS persistence using different configuration approaches for DNS-only load balancing. --- ## DNS-only load balancing persistence For DNS-only load balancing, Cloudflare offers three methods to achieve DNS persistence: ### Method 1: Geo-steering based on PoP location (Recommended) This method uses geographic steering based on the Cloudflare Point of Presence (PoP) that receives the DNS request. #### Configuration steps 1. Create a pool for each endpoint. Do not apply load shedding to either pool. 2. Create a DNS-only load balancer and add both pools. Ensure `pool_1` is ordered before `pool_2`. 3. Under **Traffic Steering**, select **Geo Steering**. 4. Create a geo-steering rule for a region (for example, **Eastern North America**) and select the same pools but in reverse order (`pool_2` first, then `pool_1`). 5. Use **Never prefer ECS** and **PoP location** to determine the source of the request. #### How it works All requests received at Cloudflare PoPs in the specified region are sent to one endpoint, while requests from other regions are sent to the other endpoint. #### Why this is recommended Using the Cloudflare PoP that received the request as criteria for steering is more stable than IP hashing or splitting IP space, as it is not affected by recursive DNS providers using different egress IPs. ### Method 2: Load shedding with IP hash This method uses load shedding to distribute traffic based on the source IP address of the recursive DNS resolver. #### Configuration steps 1. Create a pool for each endpoint (for example, `pool_1` with `endpoint_1` and `pool_2` with `endpoint_2`). 2. On the first pool, select **Hash** under **Endpoint Steering**. 3. Configure **Load Shedding**: - **Policy**: IP Hash - **Shed %**: 50% (to split traffic evenly between two pools) 4. Create a DNS-only load balancer and add both pools. Ensure `pool_1` is ordered before `pool_2`. 5. Do not configure additional traffic steering or rules. #### How it works This configuration sheds half of the requests to the second pool using an IP hash and respects session affinity per source IP of the recursive resolver. #### Limitations Some recursive DNS providers (like Google DNS 8.8.8.8 or Quad9 9.9.9.9) may use different egress IPs randomly, which can reduce persistence stability. ### Method 3: Custom rules with IP source filtering This method uses custom rules to split traffic based on IP address ranges. #### Configuration steps 1. Create a pool for each endpoint. Do not apply load shedding to either pool. 2. Create a DNS-only load balancer and add both pools. Ensure `pool_1` is ordered before `pool_2`. 3. Do not configure traffic steering. 4. Create a **Custom Rule** with: - **Field**: IP Source Address - **Operator**: is in - **Value**: A subset of IP space (for example, `0.0.0.0/1` for the lower half of IPv4 space) 5. For the rule action, choose **Override** > **Endpoints** and set the pools in reverse order (`pool_2`, `pool_1`). #### How it works Traffic with source IPs in the lower half of IPv4 space is sent to one endpoint, while traffic in the upper half is sent to the other endpoint. #### Limitations Similar to Method 2, this approach may be less stable with recursive DNS providers that use varying egress IPs. --- ## Related resources - [Session Affinity](/load-balancing/understand-basics/session-affinity/) - [Load Shedding](/load-balancing/additional-options/load-shedding/) - [Geo Steering](/load-balancing/understand-basics/traffic-steering/steering-policies/geo-steering/) - [Custom Rules](/load-balancing/additional-options/load-balancing-rules/) # Additional configuration Beyond [creating a simple load balancer](/load-balancing/load-balancers/create-load-balancer/), you may want to further customize how your load balancer routes traffic or integrate your load balancer with other Cloudflare products. ## Customize load balancer behavior - Route traffic according to characteristics of each request by [creating custom rules](/load-balancing/additional-options/load-balancing-rules/) - Protect at-risk endpoints from reaching failover by [setting up load shedding](/load-balancing/additional-options/load-shedding/) - Take endpoints out of rotation for [planned maintenance](/load-balancing/additional-options/planned-maintenance/) - Return endpoint hostnames as `CNAME` records to support downstream DNS steering with [CNAME flattening for endpoints](/load-balancing/additional-options/cname-flattening/) ## Integrate with other Cloudflare products - Bring load balancing to your TCP or UDP applications with [Cloudflare Spectrum](/load-balancing/additional-options/spectrum/) - Further secure endpoint access with [Cloudflare Tunnel](/load-balancing/additional-options/cloudflare-tunnel/) ## Integrate with 3rd parties - Increase visibility by [sending health monitor notifications to PagerDuty](/load-balancing/additional-options/pagerduty-integration/) # Load Balancing with the China Network To enable load balancers to be deployed to the [China Network](/china-network/), your zone will need to meet the following two criteria: 1. A valid [ICP license](/china-network/concepts/icp/) for the zone in question. 2. The zone must be provisioned with access to the China Network. Once these two criteria are met, any newly created load balancer will be automatically deployed to the China Network. When choosing a region for a pool's health checks, `China` is now available to be selected in both the dashboard and API. You can also create a load balancer by sending a `POST` request to the following endpoint. To deploy to the China Network with the API, the `networks` array in the API call must contain `jdcloud` as a value in addition to `cloudflare`. Refer to the [Cloudflare API documentation](/api/resources/load_balancers/methods/create/) for details on the required fields and their formats. ```bash https://api.cloudflare.com/client/v4/zones/{zone_id}/load_balancers ``` ## Limitations Load balancers deployed to the China Network currently have the following limitations: - Only cookie-based session affinity is supported. - Private network off-ramps (Tunnel, GRE, IPsec) are not supported. - Private Network Load Balancing is not available on the China Network. # Load shedding Use load shedding to prevent an at-risk endpoint from [becoming unhealthy](/load-balancing/understand-basics/health-details/) and starting the failover process. Once you configure load shedding on a pool, that pool will begin diverting traffic to other pools according to your load shedding settings and the load balancer's [steering policy](/load-balancing/understand-basics/traffic-steering/steering-policies/). ## Step 1 — Identify at-risk endpoints Using your internal metrics, identify endpoints at risk of reaching their failure threshold. - If your endpoint is seeing increased traffic but is not yet at risk of failure, start with [Step 2](#step-2--shed-default-traffic-from-a-pool). - If your endpoint is about to fail, start with [Step 4](#step-4--shed-additional-traffic-optional). ## Step 2 — Shed default traffic from a pool Once you have identified an at-risk endpoint, shed a small amount of **Default** traffic from that endpoint's pool. This traffic is not affiliated with existing [Session affinity](/load-balancing/understand-basics/session-affinity/) sessions. Configure load shedding via the [dashboard](#configure-via-dashboard) or the [API](#configure-via-api). ### Configure via dashboard To enable load shedding for a specific pool via the dashboard: 1. Go to **Load Balancing**. 2. Select the **Pools** tab. 3. On a pool, select **Edit**. 4. Open the **Configure Load Shedding** dropdown. 5. For **Default traffic**, select a **Policy** and a **Shed %**: **Policy options** When shedding **Default traffic**, you have two **Policy** options: - **Random**: Randomly sheds the percentage of requests specified in the _Shed %_. Distributes traffic more accurately, but may cause requests from the same IP to hit different endpoints. - **IP hash**: Sheds the percentage of IP address hash space specified in the _Shed %_. Ensures requests from the same IP will hit the same endpoint, but may shed a significantly higher or lower percentage of requests. For more guidance on choosing a policy, refer to [Shedding policies](#shedding-policies). **Shed %** When choosing a **Shed %**, start with a small percentage and increase gradually. Particularly if you choose the [IP hash shedding policy](#shedding-policies), you might shed more traffic than expected. ### Configure via API To enable load shedding for a specific pool via the API, [update the values](/api/resources/load_balancers/subresources/pools/methods/update/) for the pool's `load_shedding` object. **Example request** ```bash title="Request" curl --request PATCH \ "https://api.cloudflare.com/client/v4/accounts/{account_id}/load_balancers/pools/{pool_id}" \ --header "Authorization: Bearer " \ --header "Content-Type: application/json" \ --data-binary '{ "load_shedding": { "default_percent": 20, "default_policy": "random", "session_percent": 0, "session_policy": "hash" } }' ``` For more guidance on choosing a shedding policy, see [Shedding policies](#shedding-policies). ## Step 3 — Monitor traffic Once you have started shedding default traffic, evaluate the effects by reviewing the [**Overview** metrics](/load-balancing/reference/load-balancing-analytics/) in Load Balancing analytics. Based on these numbers and your internal metrics, you will know whether you need to divert additional traffic from the pool. If you see increased traffic to a pool, you may need to shed additional traffic. Pools shed a percentage of total traffic, so any increase in total traffic will also increase the traffic reaching your pool. ## Step 4 — Shed additional traffic (optional) If you need to shed additional pool traffic: 1. Follow the steps outlined in [Step 2](#step-2--shed-default-traffic-from-a-pool). - In the dashboard, increase the **Shed %** for **Default traffic** and/or **Session affinity traffic**. - For the API, increase the value for `default_percent` and/or `session_percent`. Since shedding **Session Affinity traffic** will disrupt [existing sessions](/load-balancing/understand-basics/session-affinity/) and may degrade the customer experience, only enable this option if your pool is in imminent danger of becoming unhealthy or your pool has a high percentage of traffic related to existing sessions. For more guidance, see [Shedding policies](#shedding-policies). ## Step 5 — Disable load shedding Once an endpoint is no longer at risk, remove load shedding from the pool. To remove load shedding in the dashboard, perform the same steps as [Configure load shedding via the dashboard](#configure-via-dashboard) but set the **Shed %** to `0` for both **Default traffic** and **Session affinity traffic**. To remove load shedding via the API, perform the same steps as [Configure load shedding via the API](#configure-via-api) but set the `load_shedding` object to `null`. ## Additional notes ### Shedding policies For **Default traffic**, you have two choices for shedding policy. A _Random_ policy: - Randomly sheds the percentage of requests specified in the _Shed %_. - Distributes traffic more accurately because it sheds at the request level. - May cause requests from the same IP to hit different endpoints, potentially leading to cache misses, inconsistent latency, or session disruption for [DNS-only load balancers](/load-balancing/understand-basics/proxy-modes/#dns-only-load-balancing). An _IP hash_ policy: - Sheds the percentage of IP address hash space specified in the _Shed %_. - Ensures requests from the same IP will hit the same endpoint, which will increase cache hits, provide consistent latency, and preserve sessions. - Can over- or under-shed requests, since hashing does not guarantee a perfectly even IP distribution and individual IPs may be responsible for different percentages of your requests. Choose a _Random_ policy when you want a more accurate distribution of raw requests and an _IP hash_ policy when you want to prevent a single IP from flapping between different endpoints. For **Session Affinity traffic**, you can only use an _IP hash_ policy since these requests relate to existing sessions. Only increase the _Shed %_ if you are comfortable disrupting [existing sessions](/load-balancing/understand-basics/session-affinity/). ### Fallback pools If all pools within a load balancer have _Load shedding_ enabled, some traffic will go to the fallback pool. To prevent any traffic from reaching the fallback pool, ensure at least one pool within the load balancer **does not** have load shedding enabled. ### Pools in multiple load balancers If you enable load shedding on a pool, it will shed the same percentage of traffic across all your load balancers. If you need an endpoint to shed different percentages of traffic for different load balancers, put that endpoint in multiple pools. # Override HTTP Host headers When your application needs specialized routing (`CNAME` setup or custom hosts like Heroku), you can customize the `Host` header used in health monitors on a per-endpoint or per-monitor level. :::caution[Important] If you set a header override on an individual endpoint, it will take precedence over a header override set on a monitor. Also, if you configure an [Origin Rule](/rules/origin-rules/) that overrides the hostname and set up a header override in your Load Balancer configuration, the Load Balancer configuration will take precedence over the Origin Rule hostname override. ::: ## Per endpoint Host header override To balance traffic across multiple hosts, add `Host` headers to individual endpoints within the same pool. For example, you might have a pool with endpoints hosted in multiple AppEngine projects or Amazon S3 buckets. You also might want to set up specific failover endpoints within a pool. Since these examples require specific hostnames per endpoint, your load balancer will not properly route traffic *without* a `Host` header override. If you need an endpoint `Host` header override, add it when [creating](/load-balancing/pools/create-pool/) or editing a pool. For security reasons, this header must meet one of the following criteria: * Is a subdomain of a zone associated with this account * Matches the endpoint address * Publicly resolves to the endpoint address ## Host header prioritization If you set a header override on an individual endpoint, it will take precedence over a header override set on a monitor during health monitor requests. For example, you might have a load balancer for `www.example.com` with the following setup: * Pools: * Pool 1: * Endpoint 1 (`Host` header set to `lb-app-a.example.com`) * Endpoint 2 * Pool 2: * Endpoint 3 * Endpoint 4 (`Host` header set to `lb-app-b.example.com`) * Monitor (`Host` header set to `www.example.com`) In this scenario, health monitor requests for **Endpoint 1** would use `lb-app-a.example.com`, health monitor requests for **Endpoint 4** would use `lb-app-b.example.com`, and all other health monitor requests would default to `www.example.com`. For more information on updating your custom host configuration to be compatible with Cloudflare, see [Configure Cloudflare and Heroku over HTTPS](/support/third-party-software/others/configure-cloudflare-and-heroku-over-https/). For a list of endpoints that override a monitor's `Host` header: 1. On a monitor, select **Edit**. 2. Select **Advanced health monitor settings**. 3. If you have endpoint overrides, you will see **Endpoint host header overrides**. ![Example configuration of endpoint host header overrides](~/assets/images/load-balancing/origin-host-header-override.png) # Integrate with PagerDuty To integrate Cloudflare health monitor notifications with PagerDuty, follow the steps outlined in PagerDuty’s [Email Integration Guide](https://www.pagerduty.com/docs/guides/email-integration-guide/). If you do not have a PagerDuty account, you will first need to set that up. PagerDuty will generate an email address that will create incidents based on emails sent to that address. For help locating that email address, refer to the [PagerDuty documentation](https://www.pagerduty.com/docs/guides/email-integration-guide/). When creating the Notifier object, configure the email to go to the PagerDuty integration email. Consequently, whenever a pool or endpoint goes down, an Incident will be created to capture it. # Perform planned maintenance When you change application settings or add new assets, you will likely want to make these changes on one endpoint at a time. Going endpoint by endpoint reduces the risk of changes and ensures a more consistent user experience. To take endpoints out of rotation gradually (important for session-based load balancing), [enable endpoint drain](#gradual-rotation) on your load balancer. This option is only available for [proxied load balancers (orange-clouded)](/load-balancing/understand-basics/proxy-modes/). To direct traffic away from your endpoint immediately, [adjust settings on the pool or monitor](#immediate-rotation). :::note If you want to divert traffic from an endpoint to prevent it from becoming unhealthy, use [Load Shedding](/load-balancing/additional-options/load-shedding/) instead. ::: :::caution[Existing connections are not terminated] When an endpoint becomes unhealthy, Cloudflare Load Balancing stops routing **new** requests to it. However, existing connections (including long-lived WebSocket connections) are **not** terminated — they remain open until they close naturally. If you need graceful connection draining, use [endpoint drain](#gradual-rotation) to proactively take endpoints out of rotation before maintenance, rather than relying on health check failures alone. ::: ## Before you begin Before disabling any endpoint, review the settings for any affected load balancers and pools. If a pool falls below its **Health Threshold**, it will be considered **Unhealthy** and — depending on the load balancer setup and steering policy — a load balancer may begin routing traffic away from that pool. ## Gradual rotation :::note Endpoint drain is only available for [proxied load balancers (orange-clouded)](/load-balancing/understand-basics/proxy-modes/). ::: With [session-based load balancing](/load-balancing/understand-basics/session-affinity/), it is important to direct all requests from a particular end user to a specific endpoint. Otherwise, information about the user session — such as items in their shopping cart — may be lost and lead to negative business outcomes. To remove an endpoint from rotation while still preserving session continuity, set up **Endpoint drain** on a load balancer: 1. On a new or existing load balancer, go to the **Hostname** step. 2. Make sure you have enabled **Session Affinity**. 3. For **Endpoint drain duration**, enter a time in seconds. If this value is less than the **Session TTL** value, you will affect existing sessions. ![Example configuration of session affinity with endpoint drain](~/assets/images/load-balancing/session-affinity-3.png) 4. Save your changes to the load balancer. 5. Click **Manage Pools**. 6. Disable an endpoint. Your load balancer will gradually drain sessions from that endpoint. 7. On your load balancer, expand your pools to find the disabled endpoint. You will see the estimated **Drain Time** counting down. ![Example showing load balancer draining in progress](~/assets/images/load-balancing/session-affinity-4.png) 8. When a drain is **Complete**, there are no longer any connections to that endpoint. ![Example showing load balancer draining complete](~/assets/images/load-balancing/session-affinity-5.png) 9. Perform your required maintenance or upgrades. 10. To bring your endpoint back online, re-enable the endpoint. ## Immediate rotation To direct traffic away from an endpoint immediately: 1. Do one of the following actions: * On the endpoint's [monitor](/load-balancing/monitors/), update the monitor settings so the endpoint will fail health monitor requests, such as putting an incorrect value for the **Response Body** or **Response Code**. * On the pool, disable the endpoint. * On the pool, set the [endpoint weight](/load-balancing/understand-basics/traffic-steering/origin-level-steering/#weights) to `0` (though traffic may still reach the endpoint if it is included in multiple pools). 2. Monitor [Load Balancing Analytics](/load-balancing/reference/load-balancing-analytics/) to make sure no requests are reaching the pool. * If you are using [DNS-only load balancing (gray-clouded)](/load-balancing/understand-basics/proxy-modes/), changes may be delayed due to DNS resolver caching. 3. Perform your required maintenance or upgrades. 4. Undo the changes you made in **Step 1**. # Spectrum You can configure [Spectrum](/spectrum/) with Load Balancing to bring resiliency to your TCP or UDP based applications. Leverage health monitors, failover, and traffic steering by selecting a load balancer as **Origin** when creating your Spectrum application. The exact settings will vary depending on your use case. Refer to the following steps to understand the workflow. --- ## Set up ### 1. Configure your load balancer 1. In the Cloudflare dashboard, go to the **Load Balancing** page. https://dash.cloudflare.com/?to=/:account/load-balancing 2. Select an account where the Load Balancing add-on is [enabled](/load-balancing/get-started/enable-load-balancing/). 3. Go to **Load Balancing** and select **Create load balancer**. 4. On the **Load Balancer Setup**, select **Public load balancer** 5. Choose the website to which you want to add this load balancer. 6. On the **Hostname** page, define the settings presented and select **Next**. - Enter a **Hostname**, which is the DNS name at which the load balancer is available. For more details on record priority, refer to [DNS records for load balancing](/load-balancing/load-balancers/dns-records/). :::caution To prevent issues with DNS resolution, the load balancer hostname should be different from the hostname (or domain) you intend to define for your Spectrum application. ::: - Keep the orange cloud icon enabled, meaning the load balancer is proxied. This refers to the [proxy mode](/load-balancing/understand-basics/proxy-modes/) and, with Spectrum, traffic is always proxied. - Keep **Session Affinity** and **Failover across pools** disabled as these features are not supported with Spectrum. 7. On the **Add a Pool** page, define the settings presented and select **Next**. - Select one or more existing pools or [create a new pool](/load-balancing/pools/create-pool/#create-a-pool) [^1]. - If needed, update the [fallback pool](/load-balancing/understand-basics/health-details/#fallback-pools) [^2]. 8. On the **Monitors** page, define the settings presented and select **Next**. - Review the monitors attached to your pools. - If needed, you can attach an existing monitor or [create a new monitor](/load-balancing/monitors/create-monitor/#create-a-monitor). :::caution[IP Access Rules and health checks] If your Spectrum application is used as a Load Balancer endpoint and has [IP Access Rules](/spectrum/reference/configuration-options/#ip-access-rules) enabled, Cloudflare's health check probes must be allowed by your rules. Otherwise, health checks will be blocked and all endpoints will be marked as unhealthy. To resolve this, add [Cloudflare IP addresses](https://www.cloudflare.com/ips/) to your IP Access Rules allowlist. Refer to [Spectrum Troubleshooting](/spectrum/reference/troubleshooting/#health-checks-fail-when-ip-access-rules-are-enabled) for details. This does not apply when the Spectrum application's origin is a Load Balancer hostname. In that architecture, the monitor probes the origin directly and is not affected by IP Access Rules on the Spectrum app. ::: 9. On the **Traffic Steering** page, choose an option for [Traffic steering](/load-balancing/understand-basics/traffic-steering/steering-policies/) and select **Next**. 10. Keep **Custom Rules** page empty as this feature is not supported with Spectrum. 11. On the **Review** page: - Review your configuration and make any changes. - If you set traffic steering to **Off**, re-order the pools in your load balancer to adjust the fallback order. - If you chose to set traffic steering to Random, you can [set weights to your pools](/load-balancing/understand-basics/traffic-steering/steering-policies/standard-options/#random-steering) (via the [API](/api/resources/load_balancers/methods/create/)) to determine the percentage of traffic sent to each pool. - Choose whether to **Save as Draft** or **Save and Deploy**. ### 2. Configure your Spectrum application --- ## Limitations [^1]: Within Cloudflare, pools represent your endpoints and how they are organized. As such, a pool can be a group of several endpoints, or you could also have only one endpoint (an origin server, for example) per pool. [^2]: A fallback pool is the pool of last resort. When all pools are disabled or unhealthy, this is where the load balancer will send traffic. # Actions Add **actions** to customize how your load balancer responds to certain HTTP requests. Each load balancing rule includes one or more actions. ## Supported Actions This table lists the actions available for Load Balancing rules. For a walkthrough, refer to [Create Load Balancing rules](/load-balancing/additional-options/load-balancing-rules/create-rules/).
Action Options Description
Fixed response N/A Respond to the request with an HTTP status code and an optional message.
Override Session affinity Set the session affinity for the request. You can customize cookie behavior and session time-to-live (TTL).
Override Load balancer TTL Customize the load balancer session time-to-live (TTL).
Override Steering policy Update the steering policy associated with your load balancer.
Override Fallback pool Update the fallback pools associated with your load balancer.
Override Pools Update the pools associated with your load balancer.
Override Region pools Update the region pools associated with your load balancer.
Override Country pools Update the country pools associated with your load balancer.
Override Terminates Stop processing Load Balancing rules and apply the current load balancing logic to the request.
# Create custom rules Create and manage [Load Balancing rules](/load-balancing/additional-options/load-balancing-rules/) in the **Custom Rules** page, which is part of the Create/Edit Load Balancer workflow found in **Traffic** in the dashboard. *** ## Prerequisites * **Understand whether Cloudflare proxies your traffic**: Depending on the [proxy status](/load-balancing/understand-basics/proxy-modes/) of your traffic, you may have access to different fields for your load balancing rules. For more details, refer to [Supported fields and expressions](/load-balancing/additional-options/load-balancing-rules/reference/). *** ## Example Workflow 1. In the Cloudflare dashboard, go to the **Load Balancing** page. https://dash.cloudflare.com/?to=/:account/load-balancing 2. Edit an existing load balancer or [create a new load balancer](/load-balancing/load-balancers/create-load-balancer/). 3. From the Load Balancer workflow, select **Custom Rules**. 4. Select **Create Custom Rule**. 5. In the **Field** drop-down list, choose an HTTP property. For more details, refer to [Supported fields](/load-balancing/additional-options/load-balancing-rules/reference/). 6. In the **Operator** drop-down list, choose an operator. For more details, refer to [Operators](/load-balancing/additional-options/load-balancing-rules/reference/#operators-and-grouping-symbols). 7. Enter the value to match. When the field is an ordered list, **Value** is a drop-down list. Otherwise, **Value** is a text input. 8. (Optional) To create a compound expression using logical operators, select **And** or **Or**. 9. For an action, choose **Respond with fixed response** or **Override** and enter additional details. For a full list of actions, refer to [Actions](/load-balancing/additional-options/load-balancing-rules/actions/). 10. (Optional) Select **Add another override**. 11. After you create your rule, select **Save and Deploy** or **Save as Draft**. 12. Select **Next** and review your changes. 13. Select **Save** to confirm. :::caution[Warning] To save a new load balancer rule, make sure to save both the rule **and** the overall load balancer configuration. ::: :::note In general, for non-terminating actions, the last change made by rules within the same [phase](/ruleset-engine/about/phases/) will win (later rules can overwrite changes made by previous ones). However, for [terminating actions](/ruleset-engine/rules-language/actions/), such as Block, Redirect, or any of the challenge actions, rule evaluation will stop and the action is executed immediately. Load Balancer Custom Rules override the default Load Balancer settings, including pool and origin selection. These are non-terminating actions, so the last rule applied will override any prior rules. ::: ## Example use case ### URL-based routing If you want to host `example.com/blog` separately from your main website, for example, use the following custom rule. When incoming requests match: | Field | Operator | Value | | -------- | -------- | ------- | | URI Path | contains | `/blog` | Then: | Action | Options | Value | | --------- | ------- | --------------- | | Overrides | Pools | `` | # Expressions [Load Balancing rules](/load-balancing/additional-options/load-balancing-rules/) use two kinds of expressions: * [Simple expressions](#simple-expressions) compare a value from an HTTP request to a value defined in the expression. A simple expression is identified by the presence of a **comparison operator** (*equals* or *less than*, for example). * [Compound expressions](#compound-expressions) combine two or more simple expressions into a single expression. Compound expression contains a **logical operator** (*and*, *or*, for example). With compound expressions you can tailor rules to specific use cases with a high degree of accuracy and precision. *** ## Simple expressions Simple expressions are composed of three elements: 1. A **field** that represents a property of an HTTP request. 2. A representative **value** for that field which Cloudflare compares to the actual request value. 3. A **comparison operator**, which specifies how the value defined in the expression must relate to the actual value from the request for the operator to return `true`. When the comparison operator returns `true`, the request matches the expression. This example expression returns true when a request URI path contains `/content`: ```sql (http.request.uri.path contains "/content") ``` In general, simple expressions use this pattern: ```sql ``` For more details, refer to [Supported fields and operators](/load-balancing/additional-options/load-balancing-rules/reference/). *** ## Compound expressions A compound expression uses a **logical operator** (*and*, *or*, for example) to combine two or more expressions. Compound expressions allow you to build complex statements within a single expression. The example expression below returns true when both the HTTP request URI path contains `/content` and the query string contains `webserver`: ```sql (http.request.uri.path contains "/content") and (http.request.uri.query contains "webserver") ``` In general, compound expressions use this pattern: ```sql ``` A compound expression can be an operand of a logical operator. This allows multiple operators to construct a compound expression from many individual expressions. For more details, refer to [Supported fields and operators](/load-balancing/additional-options/load-balancing-rules/reference/). *** ## Working with expressions The Expression Builder’s visual interface allows you to build expressions without worrying about field names and syntax. By comparison, the Expression Editor is text only, but it supports advanced features not available in the builder. ### Expression Builder Compound expressions are easier to scan when displayed in the Expression Builder’s visual interface, and the Expression Preview is a great reference for learning to write more advanced expressions. This Expression Builder screenshot shows the example compound expression described earlier. Compound expressions are easier to scan when displayed in the Expression Builder’s visual interface. ![Example rule configuration visible in the Expression Builder](~/assets/images/load-balancing/rules-builder-1.png) The **Expression Preview** displays the expression in text: ```sql (http.request.uri.path contains "/content") and (http.request.uri.query contains "webserver") ``` For a walkthrough, refer to [Creating Load Balancing rules](/load-balancing/additional-options/load-balancing-rules/create-rules/). ### Expression Editor The Expression Editor is a text-only interface for creating Load Balancing expressions. Although it lacks the visual simplicity of the Expression Builder, the Expression Editor supports advanced features such as support for grouping symbols (parentheses). To access the Expression Editor in the **Traffic** app, click **Edit expression** in the **Create Custom Rule** dialog. To return to the builder, click **Use expression builder**. ### Rules lists Load Balancing Custom Rules does not support IP list operators. # Custom load balancing rules ## How custom rules work As with [WAF custom rules](/waf/custom-rules/), each load balancing custom rule is a combination of two elements: an [expression](/load-balancing/additional-options/load-balancing-rules/expressions/) and an [action](/load-balancing/additional-options/load-balancing-rules/actions/). Expressions define the criteria for an HTTP request to trigger an action. The action tells Cloudflare how to handle the request. You can [create Load Balancing rules](/load-balancing/additional-options/load-balancing-rules/create-rules/) whenever you create or edit a load balancer in **Load Balancing**. When building expressions for Load Balancing rules, refer to [Supported fields and operators](/load-balancing/additional-options/load-balancing-rules/reference/) for definitions and usage. ## Availability By default, non-Enterprise customers have **one** Load Balancing rule **per load balancer hostname**. For more rules, upgrade to [Enterprise](https://www.cloudflare.com/enterprise/). ## Limitations At the moment, you cannot use Load Balancing rules with [Cloudflare Spectrum](/spectrum/about/load-balancer/). Custom rules can override [Geo steering](/load-balancing/understand-basics/traffic-steering/steering-policies/geo-steering/) pool mappings for matched requests. Specify different region, country, or data center pools in the rule. Changing only the steering policy does not disable Geo steering. Cloudflare still resolves pools from the configured topology before applying that policy. Custom rules do work alongside [pool sets](/load-balancing/understand-basics/traffic-steering/pool-sets/). Cloudflare evaluates pool sets first, then applies custom rule overrides on top of the result. A pool set that returns a fixed response is the complete response, so custom rules are not evaluated for that request. # Supported fields and operators The fields that are supported by load balancing rules depend on whether Cloudflare proxies the traffic going through your load balancer or not. If you use the wrong set of fields, you might see unexpected behaviors. For best results, use the fields associated with your traffic's [proxy status](/load-balancing/understand-basics/proxy-modes/). Also, some Load Balancing rules fields are available on the Expression Builder - as described in [Load Balancing expressions](/load-balancing/additional-options/load-balancing-rules/expressions/#working-with-expressions) - while others can only be configured manually, via API or [Expression Editor](/load-balancing/additional-options/load-balancing-rules/expressions/#expression-editor) ## Expression Builder field sets Consider the following table to know how the fields available in the [Expression Builder](/load-balancing/additional-options/load-balancing-rules/expressions/#expression-builder) are grouped. | Field Set | Section in Expression Builder | Description | | ----------------------------------------------------------------------------- | ----------------------------- | -------------------------------------------------------------------------------- | | [Fields supported regardless of proxy](#fields-supported-regardless-of-proxy) | `BOTH` | Values that are always accessible regardless of the load balancer proxy status. | | [Proxied-only fields](#proxied-only-fields) | `PROXIED ONLY` | Values accessible only when the load balancer is proxied. | | [Unproxied-only fields](#unproxied-only-fields) | `NON-PROXIED ONLY` | Values accessible only when the load balancer is not proxied (DNS-only traffic). | ![Choose load balancer fields based on the proxy status header](~/assets/images/load-balancing/proxy-status.png) ## Fields supported regardless of proxy Regardless of your traffic [proxy status](/load-balancing/understand-basics/proxy-modes/), Load Balancing rules can access values for the following fields:
Field Name in Expression Builder Description
cf.load_balancer.name
`Bytes` 		Load Balancer Name

Represents the name of the load balancer executing these rules.

Example value:
lb.example.com

cf.load_balancer.region
`Bytes` 		Load Balancer Region

Provides the{" "} region name {" "} of the data center processing the request.

Example value:
ENAM

ip.src
`IP address` 		IP Source Address

If proxied, this field provides the client TCP IP address, which may be adjusted to reflect the actual address of the client by using HTTP headers such as X-Forwarded-For or X-Real-IP .

If unproxied (DNS-only), this field provides the ECS source address, if available. If not available, it provides the client resolver IP address.

Deprecation Warning: In the future, this field will always be set to the client resolver IP address for unproxied requests. To check for the presence of ECS and use the ECS IP, see the fields{" "} dns.rr.opt.client {" "} and{" "} dns.rr.opt.client.addr , respectively.

Example value:
1.2.3.4

ip.src.asnum
`Number` 		AS Number

The 16-bit or 32-bit integer representing the Autonomous System (AS) number associated with the client IP address.

Example value:
13335

## Proxied-only fields If your traffic is proxied through Cloudflare, you have access to all the fields listed under [Fields supported regardless of proxy](#fields-supported-regardless-of-proxy) in addition to the following fields: Many of these fields are referenced from the [Rules language documentation](/ruleset-engine/rules-language/fields/reference/).
Field Name in Expression Builder Description
http.host
`String`		 (Manual entry only)

Represents the hostname used in the full request URI.

Example value:
www.example.org

http.referer
`String`		 (Manual entry only)

Represents the HTTP Referer request header, which contains the address of the web page that linked to the currently requested page.

Example value:
Referer: htt­ps://developer.example.org/en-US/docs/Web/JavaScript

http.request.headers
`Map>`		 Header

Represents HTTP request headers as a Map (or associative array).

The keys of the associative array are the names of HTTP request headers converted to lowercase.

When there are repeating headers, the array includes them in the order they appear in the request.

Decoding: no decoding performed
Whitespace: preserved
Non-ASCII: preserved

Example:
any(http.request.headers["content-type"][*] == "application/json")

Example value:
`{"content-type": ["application/json"]}`

http.request.method
`String`		 Request Method

Represents the HTTP method, returned as a string of uppercase characters.

Example value:
GET

http.request.timestamp.sec
`Integer`		 Timestamp

Represents the timestamp when Cloudflare received the request, expressed as Unix time in seconds. This value is 10 digits long.

Example value:
1484063137

http.request.uri
`String`		 URI

Represents the URI path and query string of the request.

Example value:
/articles/index?section=539061&expand=comments

http.request.uri.args
`Map>`		 (Manual entry only)

Represents the HTTP URI arguments associated with a request as a Map (associative array).

When an argument repeats, then the array contains multiple items in the order they appear in the request.

The values are not pre-processed and retain the original case used in the request.

Decoding: no decoding performed
Non-ASCII: preserved

Example:
any(http.request.uri.args["search"][*] == "red+apples")

Example value:
`{"search": ["red+apples"]}`

http.request.uri.args.names
`Array`		 (Manual entry only)

Represents the names of the arguments in the HTTP URI query string. The names are not pre-processed and retain the original case used in the request.

When a name repeats, the array contains multiple items in the order that they appear in the request.

Decoding: no decoding performed
Non-ASCII: preserved

Example:
any(http.request.uri.args.names[*] == "search")

Example value:
["search"]

http.request.uri.args.values
`Array`		 (Manual entry only)

Represents the values of arguments in the HTTP URI query string. The values are not pre-processed and retain the original case used in the request. They are in the same order as in the request.

Duplicated values are listed multiple times.

Decoding: no decoding performed
Non-ASCII: preserved

Example:
any(http.request.uri.args.values[*] == "red+apples")

Example value:
["red+apples"]

http.request.uri.path
`String`		 URI Path

Represents the URI path of the request.

Example value:
/articles/index

http.request.uri.query
`String`		 URI Query

Represents the entire query string, without the ? delimiter.

Example value:
section=539061&expand=comments

http.request.version
`String`		 HTTP Version

Represents the version of the HTTP protocol used. Use this field when you require different checks for different versions.

Example Values:

  • HTTP/1.1
  • HTTP/3
## Unproxied-only fields If your traffic is not proxied through Cloudflare, you have access to all the fields listed under [Fields supported regardless of proxy](#fields-supported-regardless-of-proxy) in addition to the following fields:
Field Name in Expression Builder Description
dns.qry.name
`Bytes` 		Query Name

Represents the query name asked.

Example value:
example.com.

dns.qry.name.len
`Integer` 		Query Name Length

Represents the length in bytes of the query name.

Example value:
123

dns.qry.qu
`Boolean` 		Question

When true, this field indicates that the received DNS message was a question.

dns.qry.type
`Integer` 		Query Type

Represents the numeric value of the{" "} DNS query type .

Example Values:

  • 1 (A record)
  • 28 (AAAA record)
dns.rr.opt.client
`Boolean` 		( Manual entry only )

When true, this field indicates that the EDNS Client Subnet (ECS) address was sent with the DNS request.

dns.rr.opt.client.addr
`String` 		( Manual entry only )

If present, this field represents the ECS address sent with the DNS request.

Example value:
1.2.3.0

## Operators and grouping symbols - **Comparison operators** specify how values defined in an expression must relate to the actual HTTP request value for the expression to return true. - **Logical operators** combine two expressions to form a compound expression and use order of precedence to determine how an expression is evaluated. - **Grouping symbols** allow you to organize expressions, enforce operator precedence, and nest expressions. For examples and usage, refer to [Operators and grouping symbols](/ruleset-engine/rules-language/operators/) in the Rules language documentation. # Enable Load balancing is an add-on for your account, meaning your account needs a [billing profile](/billing/get-started/create-billing-profile/). To enable [Load Balancing](https://dash.cloudflare.com/?to=/:account/:zone/traffic/load-balancing): 1. In the Cloudflare dashboard, go to the **Load Balancing** page. https://dash.cloudflare.com/?to=/:account/load-balancing 2. Select **Enable Load Balancing** in the **Status** column. 3. Choose your plan options and confirm payment. # Get started Get started with load balancing in one of two ways: * [Quickstart](/load-balancing/get-started/quickstart/): Get up and running quickly with Load Balancing. * [Learning path](/learning-paths/load-balancing/concepts/): Check an in-depth walkthrough for how to plan and set up a load balancer. # Quickstart Get up and running quickly with Load Balancing. For more in-depth explanations, refer to the [Learning path](/learning-paths/load-balancing/concepts/).
--- ## Before you begin Make sure you: - Have access to multiple endpoints (origin servers, private or public IP addresses, virtual IP addresses (VIPs), etc), either physical or cloud-based. - Have access to Load Balancing, available as an [add-on](/load-balancing/get-started/enable-load-balancing/) for any type of account. - Have test and production hostnames that are covered by [SSL/TLS certificates](/load-balancing/load-balancers/dns-records/#ssltls-coverage). ## Create a monitor ### Dashboard Set up the monitor Prepare your servers ### API Set up the monitor Prepare your servers ## Create pools ### Dashboard ### API ## Confirm pool health ### Unexpected health status ## Create a load balancer on a test subdomain ### Dashboard ### API ## Optional - Review load balancing analytics As you send sample requests to your test domain, review the [load balancing analytics](/load-balancing/reference/load-balancing-analytics/) page to make sure your load balancer is distributing requests like you were expecting. ## Route production traffic ## Optional - Next steps Your load balancer should be receiving production traffic (and you can confirm this by reviewing the [analytics](/load-balancing/reference/load-balancing-analytics/)). Though your product is officially set up, you may want to consider the following suggestions. ### Usage-based notifications ### Additional configuration options You may want to further customize how your load balancer routes traffic or integrate your load balancer with other Cloudflare products: # Common configurations Consider the following sections to understand how to achieve some commonly used load balancer configurations. This page assumes you understand the Cloudflare [Load Balancing components](/load-balancing/understand-basics/load-balancing-components/) and how to create and edit each of them. ## Active - Passive Failover An **active-passive failover** sends traffic to the endpoints in your active pool until a failure threshold (configurable) is reached. At the point of failure, your load balancer then redirects traffic to the passive pool. This setup ensures uninterrupted service and helps with planned outages, but it might lead to slower traffic overall. To set up a load balancer with **active-passive failover**: 1. Create a load balancer with two pools (`primary` and `secondary`). 2. In the list of pools, set the following order: 1. `primary` 2. `secondary` 3. For **Traffic Steering**, select [**Off**](/load-balancing/understand-basics/traffic-steering/steering-policies/standard-options/#off---failover). With this setup, your load balancer will direct all traffic to `primary` until `primary` has fewer available endpoints than specified in its **Health Threshold**. Only then will your load balancer direct traffic to `secondary`. In the event that all pools are marked down, Cloudflare uses the **fallback pool**, which is the option of last resort for successfully sending traffic to an endpoint. Since the fallback pool is a last resort, its health is not taken into account, and Cloudflare reports its status as **No Health**. You can select the fallback pool via the API or in the Cloudflare dashboard. For more on working with fallback pools, refer to [Pool-level steering](/load-balancing/understand-basics/traffic-steering/steering-policies/). ## Active - Active Failover An **active-active failover** distributes traffic to endpoints in the same pool until the pool reaches its failure threshold (configurable). At the point of failure, your load balancer would then re-direct traffic to the **fallback pool**. This setup speeds up overall requests, but is more vulnerable to planned or unplanned outages. To set up a load balancer with **active-active failover**, either: * Create a load balancer with a single pool (`primary`) with multiple endpoints (`endpoint-1` and `endpoint-2`) and set the same [**Weight**](/load-balancing/understand-basics/traffic-steering/origin-level-steering/#weights) for each endpoint. * Create a load balancer with two pools (`primary` and `secondary`) and — for [**Traffic Steering**](/load-balancing/understand-basics/traffic-steering/steering-policies/) — select any option except for **Off**. :::note For more background reading on server failover and common configurations, refer to [our Learning Center](https://www.cloudflare.com/learning/performance/what-is-server-failover/). ::: # Manage load balancers
For more details about load balancers, refer to [Load balancers](/load-balancing/load-balancers/). ## Create a load balancer ### Dashboard ### API ### Sharing your load balancer with other sites You can share your load balancer with other sites in your account by [creating a canonical name (`CNAME`) record](/dns/manage-dns-records/how-to/create-dns-records/). This is useful for sharing configurations with multiple other domains so you do not have to create new load balancers for each site. You can also configure separate load balancers for each domain and reuse monitors and pools. This is especially useful for changing the failover order for different domains, such as when your `example.co.uk` server has a different failover priority from `example.com` or `example.com.au`. :::note Sharing load balancers across sites is only supported if the target zone is on a [full DNS setup](/dns/zone-setups/full-setup/). It is not supported if the target zone is on a `CNAME` setup. ::: --- ## Edit a load balancer ### Dashboard To edit a load balancer in the dashboard: 1. Go to **Load Balancing**. 2. On a specific load balancer, select **Edit**. 3. While going through the [creation workflow](#create-a-load-balancer), update settings as needed. 4. On the **Review** step, select **Save**. ### API When you edit a load balancer with the API, your request type depends on how much you want to edit. To update specific settings without having to resubmit the entire configuration, use a [PATCH](/api/resources/load_balancers/methods/edit/) request. For broader changes, use a [PUT](/api/resources/load_balancers/methods/update/) request. --- ## Delete a load balancer If you delete or disable a load balancer, your endpoint's response to requests will depend on your [existing DNS records](/load-balancing/load-balancers/dns-records/#disabling-a-load-balancer). ### Dashboard To delete a load balancer in the dashboard: 1. Go to **Load Balancing**. 2. On a specific load balancer, click **Delete**. ### API To delete a load balancer using the API, send a [DELETE](/api/resources/load_balancers/methods/delete/) request. --- ## Set up alerts You can configure alerts to receive notifications for changes in the health status of your pools or endpoints. # DNS records When you [create a load balancer](/load-balancing/load-balancers/create-load-balancer/), Cloudflare automatically creates an LB DNS record for the specified **Hostname**. This functionality allows you to use a hostname with or without an existing DNS record. Private load balancers do not receive an automatic DNS record. Instead, you can configure a hostname using your internal DNS system or by applying a [Gateway Firewall override](/cloudflare-one/traffic-controls/dns-policies/#override) to a hostname. ## Supported records For customers on non-Enterprise plans, Cloudflare supports load balancing for `A`, `AAAA`, and `CNAME` records. For customers on Enterprise plans, Cloudflare supports load balancing for `A`, `AAAA`, `CNAME`, **MX**, and **SRV** records. ## Priority order For hostnames with existing DNS records, the LB record takes precedence when it is more or equally specific: - **Scenario 1**: - **A, AAAA, or CNAME**: `x.example.com` - **LB record**: `x.example.com` - **Outcome**: LB record takes precedence because it is as specific as the DNS record. - **Scenario 2**: - **A, AAAA, or CNAME**: `y.example.com` - **LB record**: `*.example.com` (wildcard record) - **Outcome**: DNS record takes precedence because it is more specific. - **Scenario 3**: - **A, AAAA, or CNAME**: `*.example.com` - **LB record**: `*.example.com` - **Outcome**: LB record takes precedence because it is as specific as the DNS record. :::note This behavior only applies to [supported records](#supported-records) (determined by your plan type). ::: If the DNS record points to a [SaaS provider](/cloudflare-for-platforms/cloudflare-for-saas/) and an active [custom hostname](/cloudflare-for-platforms/cloudflare-for-saas/domain-support/) exists, the custom hostname will take precedence over the Load Balancing record: - **Scenario 4**: - **CNAME**: `x.example.com` with target to a Cloudflare for SaaS provider - **LB record**: `x.example.com` - **Active custom hostname on the SaaS provider side**: `x.example.com` - **Outcome**: Custom hostname takes precedence. ## Disabling a load balancer When you disable a load balancer, requests to a specific hostname depend on your existing DNS records: - If you have existing DNS records, these records will be served. - If there are no existing records, requests to the hostname will fail. In both cases, disabling your load balancer prevents traffic from going to any associated endpoint or fallback pools. If you already have an existing `A`, `AAAA`, or `CNAME` record, be aware that the change may take some time to propagate due to [Time to Live (TTL)](/dns/manage-dns-records/reference/ttl/) and any record changes is affected, as your local DNS cache may take longer to update. ## SSL/TLS coverage Due to internal limitations, on [Partial (CNAME) setup](/dns/zone-setups/partial-setup/) the Cloudflare [Universal SSL certificates](/ssl/edge-certificates/universal-ssl/) do not cover load balancing hostnames by default. This behavior will be corrected in the future. As a current workaround for a domain or first-level subdomain (`lb.example.com`), create a [proxied `CNAME`/`A`/`AAAA` record](/dns/manage-dns-records/how-to/create-dns-records/) for that hostname. For example, if your load balancer hostname was `lb.example.com`, you could create the following record solely for the purpose of SSL/TLS coverage. | Type | Name | IPv4 address | Proxy status | | ---- | ---- | ------------ | ------------ | | A | `lb` | `192.0.2.1` | Proxied | Based on the [priority order](#priority-order), it would not receive any traffic because it is as equally specific as the LB hostname. To get coverage for any deeper subdomain (`lb.dev.example.com`), purchase an [advanced certificate](/ssl/edge-certificates/advanced-certificate-manager/). # Load balancers :::note For an overview of how the Cloudflare Load Balancing solution works, refer to [Load Balancing components](/load-balancing/understand-basics/load-balancing-components/). For more background information on what load balancers are, refer to the Cloudflare [Learning Center](https://www.cloudflare.com/learning/performance/what-is-load-balancing/). ::: --- ## Common configurations For suggestions, refer to [Common load balancer configurations](/load-balancing/load-balancers/common-configurations/). ## Public vs. Private Load Balancers Public Load Balancers are designed to handle traffic from the public Internet. When deployed, they automatically receive a hostname, making them immediately accessible. These load balancers can direct traffic to a range of destinations, including public hostnames, public IP addresses, and private IP addresses. Private Load Balancers, in contrast, are meant for internal use within private networks. They do not automatically receive a hostname, but one can be assigned via Gateway Firewall Policies or through an internal DNS system. Private Load Balancers only accept traffic over a private network on-ramp, such as [the Cloudflare One Client](/warp-client/) or [Cloudflare WAN](/cloudflare-wan/). They are capable of forwarding traffic exclusively to private IP addresses. ## Load balancing and existing DNS records For details about DNS records, refer to [DNS records for load balancing](/load-balancing/load-balancers/dns-records/). ## HTTP keep-alive (persistent HTTP connection) Cloudflare maintains keep-alive connections to improve performance and reduce cost of recurring TCP connects in the request transaction as Cloudflare proxies customer traffic from its edge network to the site's origin. Ensure HTTP Keep-Alive connections are enabled on your origin. Cloudflare reuses open TCP connections for up to 15 minutes (900 seconds) after the last HTTP request. Origin web servers close TCP connections if too many are open. HTTP Keep-Alive helps avoid premature reset of connections for requests proxied by Cloudflare. ### Session cookies **When using HTTP cookies to track and bind user sessions to a specific server**, configure [Session Affinity](/load-balancing/understand-basics/session-affinity/) to parse HTTP requests by cookie header. Doing so directs each request to the correct application server even when HTTP requests share the same TCP connection due to keep-alive. **For example, F5 BIG-IP load balancers set a session cookie at the beginning of a TCP connection** (if none exists) and then ignore all cookies from subsequent HTTP requests on the same TCP connection. This tends to break session affinity because Cloudflare sends multiple HTTP sessions on the same TCP connection. Configuring the load balancer to parse HTTP requests by cookie headers avoids this issue. --- ## Create load balancers For step-by-step guidance, refer to [Create a load balancer](/load-balancing/load-balancers/create-load-balancer/). --- ## Properties For an up-to-date list of load balancer properties, refer to [Load balancer properties](/api/resources/load_balancers/methods/get/) in the Cloudflare API documentation. --- ## API commands The Cloudflare API supports the following commands for load balancers. | Command | Method | Endpoint | | ------------------------------------------------------------------------------- | -------- | ------------------------------------ | | [Create Load Balancer](/api/resources/load_balancers/methods/create/) | `POST` | `/zones/:zone_id/load_balancers` | | [Delete Load Balancer](/api/resources/load_balancers/methods/delete/) | `DELETE` | `/zones/:zone_id/load_balancers/:id` | | [List Load Balancers](/api/resources/load_balancers/methods/list/) | `GET` | `/zones/:zone_id/load_balancers` | | [Load Balancer Details](/api/resources/load_balancers/methods/get/) | `GET` | `/zones/:zone_id/load_balancers/:id` | | [Overwrite specific properties](/api/resources/load_balancers/methods/edit/) | `PATCH` | `/zones/:zone_id/load_balancers/:id` | | [Overwrite entire Load Balancer](/api/resources/load_balancers/methods/update/) | `PUT` | `/zones/:zone_id/load_balancers/:id` | # Manage monitors For more details about monitors, refer to [Monitors](/load-balancing/monitors/). --- ## Retry timing When a health check times out, Cloudflare sends retries immediately — they do not wait for the next interval. The `retries` setting defines the number of additional attempts after the initial check. For example, with five retries: - Total attempts: 1 (initial) + 5 (retries) = **6** - With a 20 s timeout: Cloudflare marks the endpoint unhealthy after approximately 120 s (6 × 20 s) - The configured interval (for example, 60 s) only applies between **successful** probe cycles, not between retries --- ## Create a monitor ### Dashboard **Set up the monitor** **Prepare your servers** **Attach the monitor to a pool** Once your monitor is created, you need to attach it to a pool: 1. Go to **Load Balancing**. 2. Select the **Pools** tab. 3. On a specific pool, select **Edit**. 4. Update the following information: - **Monitor**: Select your monitor. - **Health Monitor Regions:** Specifies geographic regions from which Cloudflare should send health monitor requests. Because of [how monitors check pool health](/load-balancing/monitors/#health-monitor-regions), selecting multiple regions could increase the load on your servers. - **Notification E-mail:** Contains email addresses that receive notifications (individual, mailing list address, PagerDuty address). 5. Select **Save**. The status of your health monitor will be _unknown_ until the results of the first check are available. ### API **Set up the monitor** **Prepare your servers** **Attach the monitor to a pool** Once your monitor is created, save its `id` property. Include this value in the `monitor` parameter when [creating your pool](/load-balancing/pools/create-pool/#create-a-pool). --- ## Edit a monitor ### Dashboard To edit a monitor in the dashboard: 1. Go to **Load Balancing**. 2. Select **Monitors**. 3. On a specific monitor, select **Edit**. 4. Update settings as needed. 5. Select **Save**. ### API When you edit a monitor with the API, your request type depends on how much you want to edit. To update specific settings without having to resubmit the entire configuration, use a [PATCH](/api/resources/load_balancers/subresources/monitors/methods/edit/) request. For broader changes, use a [PUT](/api/resources/load_balancers/subresources/monitors/methods/update/) request. --- ## Delete a monitor ### Dashboard To delete a monitor in the dashboard: 1. Go to **Load Balancing**. 2. Select the **Monitors** tab. 3. On a specific monitor, select **Delete**. ### API To delete a monitor using the API, send a [DELETE](/api/resources/load_balancers/subresources/monitors/methods/delete/) request. # Monitors Health monitor requests that result in a status change for an endpoint are recorded as events in the Load Balancing event logs. :::note Health monitors associated with load balancers are different from standalone [Health Checks](/health-checks/). For an overview of how the Cloudflare Load Balancing solution works, refer to [Load Balancing components](/load-balancing/understand-basics/load-balancing-components/). ::: --- ## Properties For an up-to-date list of monitor properties, refer to [Monitor properties](/api/resources/load_balancers/subresources/monitors/methods/list/) in our API documentation. --- ## Create monitors For step-by-step guidance, refer to [Create monitors](/load-balancing/monitors/create-monitor/). ### Monitor Groups Monitor Groups let you combine multiple health monitors into a single logical group to create more accurate, intelligent health checks for your applications. By aggregating results from several monitors, you can better reflect real application health and improve traffic steering resilience. For more details, refer to the [Monitor Groups](/load-balancing/monitors/monitor-groups/) documentation page. --- ## Health monitor regions When you [attach a monitor to a pool](/load-balancing/monitors/create-monitor/#create-a-monitor), you can select multiple regions to increase reporting accuracy. ### Configurations --- ## IPv4 and IPv6 probe behavior Health monitor probes use IPv4 by default. IPv6 probes are only sent if the endpoint address has no `A` records (only `AAAA`). Each endpoint receives one probe per interval — Cloudflare does not probe both IPv4 and IPv6 for the same endpoint. To enforce probing over IPv6, set the endpoint address to either a raw IPv6 address or a hostname that only has `AAAA` records. --- ## Host header prioritization The host headers used on health monitor requests can be configured either [on the monitor itself](/load-balancing/monitors/create-monitor/) or on the [endpoints within a pool](/load-balancing/pools/create-pool/). When a host header is specified both on the monitor and on the endpoint, the host header configured on the endpoint takes precedence over the host header configured on the monitor. When no host header is specified, Cloudflare uses the **Endpoint Address** configured on the endpoints as the host header for the health monitor requests. For more details, refer to [Override HTTP Host headers](/load-balancing/additional-options/override-http-host-headers/). --- ## API commands The Cloudflare API supports the following commands for monitors. Examples are given for user-level endpoint but apply to the account-level endpoint as well. | Command | Method | Endpoint | | ------------------------------------------------------------------------------------------------------------ | -------- | ---------------------------------------------------------- | | [Create Monitor](/api/resources/load_balancers/subresources/monitors/methods/create/) | `POST` | `accounts/:account_id/load_balancers/monitors` | | [Delete Monitor](/api/resources/load_balancers/subresources/monitors/methods/delete/) | `DELETE` | `accounts/:account_id/load_balancers/monitors/:id` | | [List Monitors](/api/resources/load_balancers/subresources/monitors/methods/list/) | `GET` | `accounts/:account_id/load_balancers/monitors` | | [Monitor Details](/api/resources/load_balancers/subresources/monitors/methods/get/) | `GET` | `accounts/:account_id/load_balancers/monitors/:id` | | [Overwrite specific properties](/api/resources/load_balancers/subresources/monitors/methods/edit/) | `PATCH` | `accounts/:account_id/load_balancers/monitors/:id` | | [Overwrite existing monitor](/api/resources/load_balancers/subresources/monitors/methods/update/) | `PUT` | `accounts/:account_id/load_balancers/monitors/:id` | | [Preview Monitor](/api/resources/load_balancers/subresources/monitors/subresources/previews/methods/create/) | `POST` | `accounts/:account_id/load_balancers/monitors/:id/preview` | ## Supported protocols The following table summarizes the different types of monitors available in Cloudflare Load Balancing, their monitoring types, and how each health check process evaluates the success criteria to determine endpoint health: | Monitor type | Monitoring type | Description | Health check process | Success criteria | | ------------ | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | HTTP/HTTPS | Public and private | Used for HTTP and HTTPS endpoints with specific protocol attributes. | The probe is configured with settings and success criteria such as Method, Simulate Zone, Follow Redirects, Request Headers, and Response Body. The probe then evaluates the configured success criteria using the HTTP protocol. Throughout the configured timeout period, the TCP connection is kept active using [keep-alives](/fundamentals/reference/tcp-connections/#tcp-connections-and-keep-alives), even if no response is received. | Success is based on meeting the configured HTTP success criteria. No response within the configured timeout and retries is considered unhealthy. | | TCP | Public and private | Checks TCP connectivity by attempting to open a connection to the endpoint. | The monitor sends a TCP SYN message to the specified port. A successful health check requires receiving a SYN/ACK message to establish the connection. The connection is closed by sending a FIN or RST packet, or by receiving a FIN packet from the endpoint. | Failure to establish a TCP connection within the configured timeout and retries is considered unhealthy. | | ICMP Ping | Public and Tunnel | Confirms basic Layer 3 (L3) connectivity to the endpoint using ICMP. The endpoints need to be allowed to reply to ICMP packets and any intervening networking equipment must support ICMP. | The monitor sends an ICMP/ICMPv6 echo request (ping) and expects an ICMP/ICMPv6 echo reply from the endpoint. | The endpoint must reply to the ICMP ping within the configured timeout and retries to be considered healthy. | | UDP-ICMP | Public and Tunnel | UDP-ICMP monitor works by sending a UDP probe packet after ICMP Ping monitor completes as healthy. | After receiving a successful ICMP reply, the monitor sends a UDP probe packet to the endpoint. If no ICMP Port Unreachable message is received, the endpoint is considered healthy. | If the monitor receives an ICMP Port Unreachable message within the configured timeout and retries, the endpoint is considered unhealthy. | | SMTP | Public | Verifies SMTP availability at the application layer. | The monitor establishes a TCP connection and sends an SMTP HELO command. It expects a reply with code 250. The monitor then sends an SMTP QUIT command, expecting a reply with code 221. At the end of each interval, the TCP connection is closed by sending a TCP FIN packet. | The endpoint must respond with correct SMTP codes (250 for HELO, 221 for QUIT) within the configured timeout and retries to be considered healthy. | # Monitor Groups Group multiple health monitors together to create sophisticated health checks for your applications, ensuring more intelligent and resilient traffic steering. You can group multiple health monitors to build sophisticated health checks that more accurately reflect your application's true health. A Monitor Group allows you to combine several independent monitors, define aggregation logic, and use the collective result to determine the health of an origin pool. Grouping multiple health monitors enables more intelligent and resilient failover. For example, you can require that both a general API gateway monitor and a specific login service monitor must be healthy for a pool to receive traffic. ## Availability Monitor Groups are only available to customers on an Enterprise plan with the Load Balancing subscription. Configuration is available via the [API](/api/resources/load_balancers/subresources/monitor_groups/methods/create/) only. :::note Pools assigned to a monitor group via the API will appear as **Not monitored** on the dashboard. ::: ## How it works When you attach a Monitor Group to a pool, the health of that pool is determined by aggregating the results of all enabled monitors within the group. The sections below explain how monitor groups influence health status, latency, and result handling. ## Endpoint health with Monitor Groups A Monitor Group determines an endpoint's health using a combination of critical monitor overrides and quorum-based consensus. **Critical Monitor Override** (`must_be_healthy`): You can designate a monitor as critical by setting `"must_be_healthy": true`. If a monitor with this setting fails its health check against an endpoint, that specific endpoint is immediately marked as unhealthy. This happens regardless of the status reported by other monitors in the group for that same endpoint. This provides a definitive override for essential services. **Quorum-Based Health**: In the absence of a failure from a `must_be_healthy` monitor, an endpoint's health is determined by a quorum of all other active monitors. - An endpoint is considered unhealthy only if more than 50% of its assigned monitors report it as unhealthy. - Monitors marked as `"monitoring_only": true` are excluded from the quorum calculation. They will still run and can trigger notifications, but they do not vote on the endpoint's health status. - Monitors marked as `disabled` will not send monitoring requests to any associated pool. They are also excluded from the quorum calculation. This quorum system prevents an endpoint from being prematurely marked as unhealthy due to a transient failure from a single, non-critical monitor. ## Latency for Steering For pools using Dynamic Steering, the pool's latency is calculated as the average latency of all its enabled, non-monitoring-only monitors. This aggregated RTT (Round Trip Time) value provides a more holistic view of an origin's performance and is used to make steering decisions. ## Result handling for different intervals If monitors in a group have different check intervals, the group uses the last available result from each monitor until it is refreshed. For example, if one monitor runs every 10 seconds and another every 30 seconds, the 30-second monitor's result is considered valid for the full 30 seconds until its next run completes. # Use Pages as an origin for Load Balancing This tutorial is intended as an introductory example of how you can leverage Cloudflare's global traffic management. The following sections will guide you through setting up an [active-passive failover](/load-balancing/load-balancers/common-configurations/#active---passive-failover) load balancer with [Cloudflare Pages](/pages/) as one of the endpoints, while also going into details about the Load Balancing dashboard workflow, and some important field values and troubleshooting. ## Use cases This setup can be useful if you are migrating your production website or application to Pages or if you just want to have a backup or a personalized web page for when your primary origin goes down. ## Before you begin Make sure you: - Are familiar with the Cloudflare [Load Balancing components](/load-balancing/understand-basics/load-balancing-components/). - Own a domain and use Cloudflare as a [primary DNS provider](/dns/zone-setups/full-setup/). - Have [deployed a website or application](/pages/get-started/git-integration/) with Cloudflare Pages. - Have [enabled Load Balancing](/load-balancing/get-started/enable-load-balancing/) in your account. ## Create health monitor Although you can create all the components in the **Create Load Balancer** workflow, using the **Manage Monitors** and **Manage Pools** sections separately makes it easier to test and troubleshoot the configurations of each of these components before bringing them together in a load balancer. Monitors define the criteria based on which an endpoint will be considered healthy or not. Start by setting up a monitor as follows. 1. In the Cloudflare dashboard, go to the **Load Balancing** page. https://dash.cloudflare.com/?to=/:account/load-balancing 2. Select the **Monitors** tab and then **Create monitor**. 3. Give the monitor a descriptive name and confirm the other fields are filled in as the following: | Field | Value | | ----- | ----- | | Type | HTTP | | Path | / | | Port | 80 | 4. Under **Advanced health check settings**, keep the default values and enable the **Follow Redirects** option. When you are using a service like Cloudflare Pages, it is possible that requests from the health monitor - as well as the ones from your visitors - are redirected before reaching their destination. Enabling this option prevents the monitor from reporting an unhealthy endpoint when it actually has only been redirected (with a `301` code, for example). :::note[Tip] You can name the monitor after the parameters you have defined. For example: `HTTP - 200 - Follow Redirects`. This way you can easily remember the criteria a certain monitor is using when you decide to attach it to other endpoints as well. ::: 5. Select **Save** to confirm. ## Create pools Pools hold information about where the health monitor requests and your visitors requests will be directed to. To support the [use cases](#use-cases) mentioned above, and assuming you only have one origin server for your production website and one for the Cloudflare Pages instance, create two pools with one endpoint each: :::caution[Important] The endpoint pointing to [Cloudflare Pages](/pages/) must have **host header** filled in with the project domain (`.pages.dev`) for it to resolve correctly. You can find a reference table for correct setup in Step 8 below. Failing to add the host header will result in [response code mismatch error](/load-balancing/troubleshooting/common-error-codes/#response-code-mismatch-error) for the monitor, and [Error 1000: DNS points to prohibited IP](/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/error-1000/) for visitors (if the load balancer is enabled despite the unhealthy monitor status). ::: 1. In the Cloudflare dashboard, go to the **Load Balancing** page. https://dash.cloudflare.com/?to=/:account/load-balancing 2. Select the **Pools** tab and then **Create monitor**. 3. For the first pool, start by filling out the fields: - A name for the pool (must be unique). Suggestion: `primary` - A description to provide more details on the name. Suggestion: `production website` 4. Leave the choice for [**Endpoint Steering**](/load-balancing/understand-basics/traffic-steering/origin-level-steering/) as is. Since each pool will only have one endpoint, this steering method will not interfere in this case. 5. Add your origin server as an endpoint with the following information: - A name for the endpoint (must be unique). Suggestion: `my-website`. - The endpoint IP address or hostname. :::caution As exemplified in Step 8 below, when using Cloudflare as an endpoint, **do not** specify one of Cloudflare's anycast IP addresses. Because these IPs can change at any time, you should use a hostname instead. ::: - The endpoint [weight](/load-balancing/understand-basics/traffic-steering/origin-level-steering/#weights), which can be set to `1`. Since each pool will only have one endpoint, the endpoint weight will not make a difference in this case. - A [hostname](/load-balancing/additional-options/override-http-host-headers/) by selecting **Add host header**. :::caution If your production website is hosted on a platform like Cloudflare Pages, where you have a default subdomain (`example.pages.dev`) and then configure a [custom domain](/pages/configuration/custom-domains) (`my-app.com`), you will need to add a host header to avoid failing the health monitor request. ::: 6. Finish configuring the first pool with the following information: - Leave the **Health Threshold** set to `1`. Since each pool will only have one endpoint, this is the only possible value for this field. - Select the **Monitor** configured in the previous step. - Select **Health Check Regions** to choose from which [locations](/load-balancing/monitors/#health-monitor-regions) Cloudflare should send monitor requests to periodically test the endpoint health. 7. Select **Save** 8. Repeat the process for the second pool using the following values: | Field | Value | | -------------------------- | ----------------------------------------- | | Pool name | `secondary` | | Description | `Pages version` | | Endpoint steering | `` | | Endpoint name | `my-pages-website` | | Endpoint address | `` | | Weight | `1` | | Host (**Add host header**) | `` | | Health threshold | `1` | | Monitor | `` | | Health check regions | `