The primary origin fails after maintenance, but traffic does not move to the backup as expected. Or the homepage still loads while login and checkout have already stopped working. Before shortening probe intervals, establish whether your setup uses standalone health monitoring, load-balancer steering, or failover triggered by an actual origin request.
These mechanisms are different. Cache hits can also keep some requests away from a failed origin, producing different results across paths, users, and edge locations. The following checks and drills are examples, not tests performed in your production environment. Validate switching changes in staging first.
Identify where switching actually happens
Map the browser, CDN, origin group, load balancer, and application. Record primary and backup addresses, trigger mechanisms, eligible methods, failure conditions, timeouts, and retry budgets. Confirm that the failover configuration is attached to the distribution behavior matched by the failing request.
A health check that sends an alert does not necessarily redirect traffic. Cloudflare standalone Health Checks and traffic-steering capabilities need to be checked against their respective product configurations. A probe alert alone does not establish that a backup pool has taken over.[2]
CloudFront origin groups use request-driven origin failover. This mechanism applies only to GET, HEAD, and OPTIONS, not to POST in the same way. Its documentation also describes primary-origin-first request handling rather than permanently routing future traffic to the backup after one failure.[1]
Successful image failover therefore does not prove that order creation has equivalent protection. Write operations need application-level consistency, idempotency, and recovery design. Increasing retries or forcing cross-origin replay is not a substitute.
Cached responses can mask an origin outage
An origin failure may not immediately break a page if the requested objects are still available at the edge. Meanwhile, cache misses, expired objects, and uncacheable APIs may already be failing. Some services can also serve stale content under specific conditions; the applicable policy determines whether that happens.[3]
Inspect cache status, Age, origin logs, and origin request counts. Individual response headers are clues, not proof: multiple intermediaries may add or rewrite them. Establish whether the relevant request actually reached the primary or backup.
Do not purge the entire production cache simply to prove the origin is unavailable. That can create a surge of origin traffic and break requests that were still being served successfully. Use a small controlled test object and an explicitly understood cache behavior.
A random query parameter may not bypass a cache whose key ignores query strings. Likewise, a client Cache-Control: no-cache request is not a universal direct-to-origin switch. Verify actual edge configuration and logs.
The health endpoint may be testing an empty shell
A static homepage can return 200 from a reverse proxy while the database, authentication service, or critical application path is broken. Conversely, including every optional dependency in readiness can cause an entire origin group to be withdrawn unnecessarily.
Distinguish liveness from readiness. Liveness asks whether a process needs restarting; readiness asks whether an instance should receive the relevant traffic. Use lightweight, read-only, low-cost checks for critical capabilities. Probes must not create orders, charge cards, or repeatedly run expensive queries.
Review the method, path, expected status, response content, Host, TLS server name, and certificate validation. A probe that follows a redirect to a login page and receives 200 may report a misleading success. If routing depends on Host, an IP-only probe may not exercise the real virtual host.
A readiness response can contain a non-sensitive marker, but it should not reveal database passwords, internal topology, or debug stacks. Control probe cost and access. Do not open real business permissions merely to make a monitor pass.
Confirm that the observed failure matches a trigger
Some applications return HTTP 200 with an error code inside JSON. Status-based origin failover generally will not treat that as an eligible HTTP failure. Review the API contract and gateway handling rather than wrapping every business failure in a success status.
CloudFront supports selected error statuses as origin-group failover criteria, while connection failures and timeouts also depend on relevant settings.[1] Do not assume every 4xx should trigger switching. Authorization failures, invalid input, or missing resources may behave identically on the backup, where another attempt merely increases load.
Evaluate connection waits, response waits, retry attempts, and the client's total timeout together. If the client gives up before the backup answers, the user still sees a failure. Extending every deadline increases resource occupancy without correcting a mismatched trigger.
Verify that the backup can serve the real workload
Check backup routing, certificates, origin Host, access controls, asset versions, and dependencies. A direct test succeeding does not establish that requests from CDN egress addresses will succeed. Firewalls, private-origin authentication, and TLS names can produce different outcomes.
Even read-only content needs matching versions and paths. Writes introduce replication lag, sessions, inventory, uploaded files, and message queues. A 200 response from a backup health endpoint is not evidence of complete cross-site business recovery.
Shared dependencies may fail both origins at once. If both use the same database or identity provider, traffic switching will not repair that dependency and may create more retries. Specify which failure modes call for switching, degraded service, or pausing writes.
Test a controlled origin path without disabling TLS validation
This Bash example applies only to an authorized, directly reachable staging origin. The hostname preserves the intended Host and TLS server name. Replace the reserved example address with your own test origin:
curl -sS --max-time 10 \ --resolve origin-test.example.com:443:192.0.2.10 \ -D probe-headers.txt -o probe-body.txt \ 'https://origin-test.example.com/readyz'
Do not add -k to conceal certificate failures. This request bypasses the CDN and cannot prove that edge failover works. It checks connectivity, TLS, and the specified response path from that test machine to that origin.
If a private origin accepts only CDN traffic, direct access failing may be correct behavior. Do not temporarily expose it publicly to run the example. Use an authorized internal probe location or provider diagnostics, and keep authentication tokens out of command history and public logs.
Exercise failure, takeover, and recovery
Back up origin-group, probe, and timeout configuration. Use staging or an approved maintenance window with an owner and stop conditions. With test resources, simulate a primary connection failure, response timeout, selected error status, and a healthy probe paired with a failing business path. Record each outcome separately.
Acceptance must inspect client results, both origins' logs, and data consistency. Confirm that the request method is eligible, the backup actually received the request, and a cache hit did not create a false success. Do not inject faults into production order or payment endpoints.
After restoring the primary, observe whether requests prefer it again, whether routing oscillates, and whether cached error responses persist. Invalidate relevant error objects only when necessary and within a defined scope. A full purge can obscure the recovery process and add load.
For rollback, restore verified routing and probe settings without forcing traffic onto an origin that remains unhealthy. Write-capable recovery also requires checking data and business state. Changing a DNS record alone is not a complete recovery drill.
The evidence should answer four questions: did the request go to an origin, did the failure meet a switching condition, could the backup answer, and did the client wait long enough? Those checks explain missing failover more reliably than simply increasing probe frequency.
References
Source review date: November 5, 2026. Features, method restrictions, and timeout behavior depend on current product documentation and actual configuration.
