{"id":210,"date":"2016-01-30T17:57:37","date_gmt":"2016-01-30T17:57:37","guid":{"rendered":"http:\/\/www.hitsteps.com\/blog\/?p=210"},"modified":"2026-08-03T04:35:24","modified_gmt":"2026-08-02T20:35:24","slug":"cloudflare-automatic-ip-failover","status":"publish","type":"post","link":"https:\/\/www.hitsteps.com\/blog\/cloudflare-automatic-ip-failover\/","title":{"rendered":"Cloudflare Automatic IP Failover: A Current, Safer Setup Guide"},"content":{"rendered":"\n<p><em>Reviewed and substantially updated in August 2026.<\/em><\/p>\n<p>The old API-v1 script previously published on this page is obsolete and should not be used. Current Cloudflare automatic failover is built around Load Balancing: health monitors check origins, origins are grouped into pools, and a load balancer routes traffic according to health and steering policy.<\/p>\n<p>This guide explains the current design, the prerequisites people often miss, and how to test a failure without turning a maintenance exercise into an outage.<\/p>\n\n<h2>What Cloudflare automatic IP failover does<\/h2>\n<p>Cloudflare <a href=\"https:\/\/developers.cloudflare.com\/load-balancing\/\" rel=\"noopener\">Load Balancing<\/a> is a paid add-on that can distribute traffic across origins and steer away from an unhealthy pool. Its core objects are:<\/p>\n<ul>\n<li><strong>Monitor:<\/strong> the request Cloudflare sends and the conditions that count as healthy.<\/li>\n<li><strong>Origin:<\/strong> an address and port serving the application.<\/li>\n<li><strong>Pool:<\/strong> one or more origins, usually representing a location or failure domain.<\/li>\n<li><strong>Load balancer:<\/strong> the hostname, pools, fallback pool, and steering policy presented to users.<\/li>\n<\/ul>\n<p>This is different from simply publishing several A records. Plain round-robin DNS distributes answers but does not necessarily perform active health checks or promptly stop returning a failed origin. See <a href=\"https:\/\/www.hitsteps.com\/blog\/dns-load-balancing-and-auto-ip-failover\/\">DNS load balancing versus health-checked failover<\/a> for the architecture trade-offs.<\/p>\n\n<h2>Before you configure failover<\/h2>\n<p>A second server is not automatically a safe failover target. Confirm these items first:<\/p>\n<ul>\n<li><strong>Application parity:<\/strong> both origins run compatible code, configuration, dependencies, and scheduled jobs.<\/li>\n<li><strong>Data consistency:<\/strong> decide how database writes, uploaded files, queues, and caches remain correct during and after a switch.<\/li>\n<li><strong>Session behavior:<\/strong> use a shared session store, stateless sessions, or intentional session affinity. Do not assume an in-memory session exists on another server.<\/li>\n<li><strong>TLS and host handling:<\/strong> each origin accepts the expected hostname and has the correct origin certificate\/configuration.<\/li>\n<li><strong>Network access:<\/strong> firewalls allow Cloudflare health probes and proxied traffic without unnecessarily exposing an administrative service.<\/li>\n<li><strong>Capacity:<\/strong> the remaining healthy pool can handle the full expected load.<\/li>\n<li><strong>Recovery ownership:<\/strong> an operator knows how to diagnose the failed origin and return it safely.<\/li>\n<\/ul>\n\n<h2>Design a useful health endpoint<\/h2>\n<p>A monitor should test the minimum path that proves the origin can serve real traffic. A TCP connection alone says that a port is open; it does not prove the application can answer correctly. Conversely, a check that depends on every downstream integration may cause unnecessary failover when a non-essential service has a brief problem.<\/p>\n<p>A dedicated endpoint such as <code>\/healthz<\/code> can return a small response with an expected status code and body. Consider whether it should verify:<\/p>\n<ul>\n<li>the web process is responsive;<\/li>\n<li>essential configuration is loaded;<\/li>\n<li>a critical database dependency is available;<\/li>\n<li>the application is ready to receive traffic rather than merely started.<\/li>\n<\/ul>\n<p>Keep the response free of secrets and sensitive diagnostics. Protect the endpoint from expensive work, make its result deterministic, and document exactly what \u201chealthy\u201d means.<\/p>\n\n<h2>Configure failover in the Cloudflare dashboard<\/h2>\n<ol>\n<li><strong>Create the monitor.<\/strong> Choose protocol, port, path, method, expected status, optional expected body, timeout, interval, and consecutive success\/failure thresholds. Cloudflare&#8217;s <a href=\"https:\/\/developers.cloudflare.com\/load-balancing\/monitors\/create-monitor\/\" rel=\"noopener\">monitor documentation<\/a> describes the available settings.<\/li>\n<li><strong>Create a primary pool.<\/strong> Add the primary origin or origins and attach the monitor.<\/li>\n<li><strong>Create a secondary pool.<\/strong> Put it in a genuinely separate failure domain where practical, then attach the same monitor or an intentionally different one.<\/li>\n<li><strong>Choose the fallback pool.<\/strong> This is used if other pools are unavailable according to the configured logic, so it must be able to serve the application safely.<\/li>\n<li><strong>Create the load balancer.<\/strong> Select the public hostname, default pool order, fallback pool, TTL\/steering options, and any session-affinity behavior your application requires.<\/li>\n<li><strong>Observe health before sending production traffic.<\/strong> Confirm every origin reports the expected state and investigate any flapping.<\/li>\n<\/ol>\n<p>Cloudflare documents pool composition and health behavior in its <a href=\"https:\/\/developers.cloudflare.com\/load-balancing\/pools\/\" rel=\"noopener\">Load Balancing pools guide<\/a>. Names and dashboard placement can change; use the current documentation rather than copying an old screenshot or API call.<\/p>\n\n<h2>If you automate it, use scoped API tokens<\/h2>\n<p>Prefer the dashboard for a one-off setup. If infrastructure automation is necessary, use the current Cloudflare API and a narrowly scoped API token. Do not paste a Global API Key into a shell script, source repository, ticket, or monitoring URL. Store secrets in the deployment platform&#8217;s secret manager, limit permissions to the required zone\/account resources, rotate credentials, and keep an audit trail.<\/p>\n<p>Make automation idempotent: reading the current configuration and applying a defined desired state is safer than a script that blindly swaps addresses. Include validation and a rollback path.<\/p>\n\n<h2>Test the design before relying on it<\/h2>\n<ol>\n<li>Record the normal pool and origin health state.<\/li>\n<li>Send a distinctive test request and confirm which origin serves it without exposing that marker to ordinary users.<\/li>\n<li>During a maintenance window, disable the primary origin in Cloudflare or make the dedicated test endpoint fail in a controlled way. Avoid crashing a production host merely to prove routing.<\/li>\n<li>Measure detection time, traffic transition, errors, session continuity, queued work, and user-visible behavior.<\/li>\n<li>Restore the primary, wait for consecutive successful checks, and confirm recovery does not cause a second disruption.<\/li>\n<li>Write down the evidence and adjust thresholds if normal latency causes false failures.<\/li>\n<\/ol>\n<p>Also test a partial failure: an application can return HTTP 200 while logins, checkout, uploads, or database writes are broken. Synthetic checks for critical user journeys may be needed in addition to the routing health endpoint.<\/p>\n\n<h2>Monitoring and failover are separate responsibilities<\/h2>\n<p>Cloudflare&#8217;s monitor informs Cloudflare&#8217;s routing decision. An independent external monitor helps confirm what a user can reach and can alert an operator if all routes fail or the DNS\/CDN layer itself is affected. Hitsteps uptime monitoring can be one external availability signal; analytics traffic is not a health check and should never control failover.<\/p>\n<p>Keep alerts actionable: include the hostname, affected pool\/origin, failing condition, start time, runbook, and owner. Avoid putting API tokens or sensitive health-response details in an alert URL.<\/p>\n\n<h2>Rollback plan<\/h2>\n<p>Before launch, export or document the prior DNS and Load Balancing configuration. Define who can:<\/p>\n<ul>\n<li>disable a failing origin;<\/li>\n<li>restore the previous pool order or hostname record;<\/li>\n<li>freeze writes if data consistency is uncertain;<\/li>\n<li>verify recovery from outside Cloudflare;<\/li>\n<li>reconcile sessions, queues, uploads, and database changes after the event.<\/li>\n<\/ul>\n<p>Automatic routing reduces time spent sending users to a known unhealthy origin. It does not solve state replication, software defects, capacity shortfalls, or a dependency shared by every pool. Treat failover as one tested layer in a broader recovery plan.<\/p>\n\n","protected":false},"excerpt":{"rendered":"<p>Configure current Cloudflare automatic IP failover with health monitors, origin pools, safe testing, scoped credentials, and a rollback plan.<\/p>\n","protected":false},"author":1,"featured_media":213,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-210","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-developers"],"_links":{"self":[{"href":"https:\/\/www.hitsteps.com\/blog\/wp-json\/wp\/v2\/posts\/210","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hitsteps.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hitsteps.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hitsteps.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hitsteps.com\/blog\/wp-json\/wp\/v2\/comments?post=210"}],"version-history":[{"count":7,"href":"https:\/\/www.hitsteps.com\/blog\/wp-json\/wp\/v2\/posts\/210\/revisions"}],"predecessor-version":[{"id":3472,"href":"https:\/\/www.hitsteps.com\/blog\/wp-json\/wp\/v2\/posts\/210\/revisions\/3472"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.hitsteps.com\/blog\/wp-json\/wp\/v2\/media\/213"}],"wp:attachment":[{"href":"https:\/\/www.hitsteps.com\/blog\/wp-json\/wp\/v2\/media?parent=210"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hitsteps.com\/blog\/wp-json\/wp\/v2\/categories?post=210"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hitsteps.com\/blog\/wp-json\/wp\/v2\/tags?post=210"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}