Cloudflare Load Balancing can direct DNS responses toward healthy origin pools according to configured steering and failover behavior. It is not an instant, universal traffic switch: recursive DNS caching, client connection reuse, monitor cadence, monitor interpretation, and origin capacity all affect what users experience. Operate it as a traffic-management control plane with explicit health semantics and tested degradation behavior.

This tutorial gives DevOps and platform engineers a conservative production workflow. It does not assume that health checks prove application correctness or that failover will occur within a fixed time.

Prerequisites

Prepare the following before creating a production load balancer:

• A Cloudflare plan and account configuration that includes the Load Balancing capabilities you intend to use. Confirm entitlement and current product constraints in Cloudflare Load Balancing.
• At least two independently operable origin pools where the service design requires failover. A second pool that shares the same failure domain is not meaningful resilience.
• An origin endpoint suitable for synthetic health checking, with documented authentication requirements, expected status code, body, and dependency scope.
• Capacity data for each origin pool, including normal load, safe sustained load, burst behavior, connection limits, autoscaling delay, and database or downstream limits.
• Access to Cloudflare DNS and Load Balancing configuration, plus origin metrics, logs, and a coordinated change window.

Stage 1: Define Route and Health Semantics

Start with the user-facing hostname and the exact request path that is being protected. Decide whether the load balancer answers the apex, a subdomain such as api.example.com, or a dedicated service hostname. The hostname must have Cloudflare DNS configuration compatible with the load balancer setup.

Then define what “healthy” means. A monitor verifies the response seen from Cloudflare’s monitoring infrastructure; it does not prove that every application journey, user location, or dependency is healthy. Cloudflare documents monitor fields and status evaluation in Monitors.

A useful health endpoint should:

• Be fast and unauthenticated from the monitor’s perspective, or use the monitor’s supported request configuration deliberately.
• Validate the dependencies whose loss should trigger traffic movement, without making the check so broad that a non-critical dependency causes unnecessary failover.
• Return the configured expected status and, when used, expected response body consistently.
• Avoid mutating data, warming expensive caches, or creating meaningful load at the monitor interval.

Document route semantics separately from health semantics. A 200 response from /healthz does not guarantee that every route, tenant, authentication flow, or write operation is usable.

Stage 2: Create Pools With Capacity Boundaries

A pool groups origins and associates monitor behavior and origin metadata. Create a pool for each traffic destination or failure domain, then add origins with the correct address, port, weight, and enabled state. Use Pools as the configuration reference.

For each pool, record:

• The pool’s intended role: primary, regional primary, standby, maintenance, or evacuation target.
• The origins it contains and shared dependencies they rely on.
• Healthy and unhealthy monitor behavior, including the endpoint, method, expected response, timeout, interval, retries, and consecutive-down criteria.
• Safe receiving capacity for traffic transferred from another pool.
• The origin-side signal that tells operators the pool is near saturation.

Do not size a standby pool only for its normal trickle of traffic. If it may receive failover traffic, validate its ability to accept that traffic and account for autoscaling time, connection pools, databases, third-party quotas, and cache cold starts. Cloudflare can choose a pool according to configuration, but it cannot create origin capacity.

Stage 3: Configure the Load Balancer and Steering

Create the load balancer for the hostname and attach ordered fallback pools. Configure steering to match the traffic-management objective, then review the applicable behavior in Steering. Available steering policies and their outcomes depend on the selected configuration; verify the Cloudflare dashboard or API representation rather than inferring behavior from a policy name.

When choosing a steering policy, define the operational question it answers:

• Geolocation-oriented steering can guide users toward designated pools, but does not by itself prove the chosen pool is fastest for every network path.
• Dynamic steering uses Cloudflare measurements and configuration to influence selection, but observed client latency still includes DNS, connection, application, and origin behavior.
• Random or weighted approaches can support controlled distribution when pools are intentionally equivalent, provided the weights reflect real capacity.
• A fixed fallback order is appropriate when the service has a clear primary and standby relationship.

Configure fallback pools deliberately. Confirm the behavior expected when an origin becomes unhealthy, when an entire pool is unhealthy, and when all candidate pools are unavailable. Cloudflare’s Load Balancing concepts describe the relationship among load balancers, pools, monitors, and steering.

Stage 4: Account for DNS Caching and TTL

Cloudflare Load Balancing influences DNS answers. It does not force every recursive resolver or client to discard a prior answer immediately. DNS TTL and resolver behavior affect when a new answer is requested, while existing connections can remain pinned to an earlier origin path.

Set the load balancer TTL as a tradeoff between agility and DNS-query volume, then verify the selected value against Cloudflare’s current DNS TTL guidance for Load Balancing. Do not promise an exact failover time based only on the monitor interval or TTL.

Plan for these effects:

• Recursive resolvers may retain an answer until its cached TTL expires; client and resolver behavior can introduce additional variation.
• Users with existing persistent connections may not observe a changed DNS answer until the connection is retried or replaced.
• Shorter TTLs can make new DNS answers available sooner, but do not eliminate monitoring detection time, resolver behavior, or origin-side recovery constraints.
• DNS health-driven changes do not repair in-flight requests already sent to an impaired origin.

If the service requires request-level proxying, session affinity, or behavior beyond DNS response steering, evaluate the relevant Cloudflare architecture separately. Do not assume Load Balancing alone supplies those properties.

Stage 5: Test the Complete Failure Path Safely

Use a staging hostname and representative pools first. Test with a controlled amount of traffic and a rollback owner present. Never begin by disabling the only healthy production origin.

Run this test plan:

1. Confirm each origin directly serves the expected application route and that its monitor endpoint returns the configured success response.
2. Confirm the load-balanced hostname returns a DNS answer associated with the intended active pool and that real requests reach it.
3. Introduce a reversible, monitor-visible failure to one origin. Verify the monitor marks it unhealthy according to its configured thresholds, then verify traffic selection avoids that origin where the configuration requires it.
4. Restore the origin. Verify monitor recovery and the configured return behavior; do not assume that recovery necessarily moves traffic immediately or automatically without checking the chosen steering and fallback rules.
5. Introduce a reversible failure affecting the active pool only after confirming the fallback pool has enough capacity. Observe both DNS answers and application outcomes across multiple resolver contexts or controlled clients.
6. Load-test the receiving pool at the expected transferred traffic level, including critical reads, writes, authentication, and downstream calls.
7. Test a partial degradation that returns 200 from the health endpoint while a critical route fails. Use the result to decide whether the monitor is intentionally narrow or insufficient for the service objective.

Record timestamps for failure injection, monitor-state change, DNS observations, first client errors, fallback capacity signals, and recovery. This establishes an observed range for this architecture, not a universal failover commitment.

Stage 6: Observe Health, Traffic, and Capacity

Watch three layers during rollout and incidents:

• Cloudflare monitor and pool health: which origins and pools Cloudflare considers healthy, and the monitor failures that changed state.
• DNS and traffic selection: query answers from representative resolvers, pool traffic distribution, and requests reaching each origin.
• Application and infrastructure health: request success rate, latency, saturation, error budget impact, database capacity, queue depth, and dependency availability.

Cloudflare provides product-specific operational workflows in Load Balancing analytics and monitoring. Pair those signals with origin telemetry; a green monitor plus a saturated origin is not a healthy service.

Alert on actionable conditions such as an active pool losing capacity, a fallback pool receiving unexpected traffic, monitor flapping, origin errors rising after a steering change, and standby capacity dropping below the required transfer margin. Include the active configuration version or change reference in the operational timeline.

Rollback

Before changing a production pool, monitor, or steering policy, capture the current configuration and name the rollback action. Keep changes small enough that an observed regression has a clear cause.

Rollback choices depend on the change:

• Restore the previous steering policy or fallback-pool order if a policy change sends traffic unexpectedly.
• Re-enable a previously healthy origin only after confirming it can safely receive traffic.
• Return a monitor to its prior endpoint or thresholds if a new check creates false unhealthy states, while investigating whether the old check masked a real service risk.
• Shift traffic away from a pool only after confirming the destination capacity and dependency limits.

After rollback, verify DNS observations, origin request distribution, monitor status, representative user flows, and receiving-pool saturation. Do not declare recovery solely because the Cloudflare configuration update succeeded.

Common Pitfalls

• Using a liveness-only endpoint to make failover decisions for a dependency-heavy application.
• Configuring a standby pool without testing its ability to absorb the transfer.
• Assuming the configured TTL equals a guaranteed client failover duration.
• Treating a healthy monitor as proof that all application routes work.
• Changing monitors, pools, weights, and steering in one release, making regressions difficult to isolate.
• Failing over to origins that share the same database, network, identity provider, or third-party dependency as the failed pool.
• Interpreting Cloudflare pool selection as a guarantee of lowest end-to-end latency for every user.

Technical Caveats

Load Balancing behavior is shaped by the configured monitor, pool health, steering policy, fallback order, DNS TTL, resolver caching, client connections, Cloudflare product settings, and origin behavior. Consult the current Cloudflare documentation before making commitments about policy availability, health detection, traffic movement, or recovery time. Define service objectives around measured user outcomes and tested capacity rather than a vendor configuration value alone.

Primary Sources

• Cloudflare Load Balancing overview
• Cloudflare Load Balancing concepts
• Cloudflare Load Balancing pools
• Cloudflare Load Balancing monitors
• Cloudflare Load Balancing steering policies
• Cloudflare Load Balancing TTL