Define the availability boundary of Cloudflare Tunnel replicas

Separate connector resilience from application health when planning multiple cloudflared replicas.

Source facts

Cloudflare documents multiple connections from a cloudflared instance to its network and supports replicas running the same tunnel on additional hosts. Remaining replicas can continue serving when one fails. Replicas do not provide configurable traffic steering: requests normally go to the closest replica, and a particular fallback choice is not guaranteed. Cloudflare identifies load balancing as the separate option for more sophisticated steering.

Source: Cloudflare — Tunnel availability.

Applicability

Use this guide to define what tunnel replication is intended to cover. A healthy connector and a successful application transaction should be separate acceptance checks in the deployment plan.

DSE recommendation

DSE recommends mapping each replica’s host, power, uplink, DNS dependencies, and path to its origin application. Decide whether the replicas still depend on one application server or another shared component. Assign monitoring for the user-facing transaction as well as connector state. Write down the intended behavior for a stopped connector, an unreachable origin, and a wider site outage before describing the design as redundant. Select any additional health-based routing only after defining that requirement.

Verification

Under an approved test window, stop one connector and observe a real application transaction through the remaining design. Test the agreed origin-failure scenario separately. Record failure scope, recovery behavior, and any interrupted sessions rather than promising uninterrupted service from replica count alone.

Official reference

Cloudflare — Tunnel availability. Reviewed October 14, 2026.