TL;DR: Cloudflare can redirect traffic away from an unhealthy backend, but the backup may still reach the same failed dependency. Anyshift connects each Cloudflare route to the production systems behind it, so automation can reject ineffective failovers and restore normal traffic only after recovery is verified.
A fallback only helps when it leaves the failure
An e-commerce site relies on checkout to turn a customer’s cart into a completed purchase. When checkout stops responding, Cloudflare Load Balancing considers moving requests from checkout-primary to the backup pool, checkout-fallback.
Cloudflare knows whether those backend addresses, called origins, answer health checks. It does not show whether they later reach the same Kubernetes workload or datastore. Those shared systems form a failure domain, meaning infrastructure that can fail together because it shares a dependency. If both origins enter the same failure domain, the configuration changes, but checkout still reaches the broken dependency. Even after the redirect, nothing is fixed.
The initial review asks what failed and whether the fallback escapes that failure. Recovery is evaluated later, before normal traffic returns.
Anyshift connects the public hostname to the running workload
Anyshift is a topology and event graph built from production data. It connects infrastructure, code, deployed state, security, and observability in a single, queryable model of what is configured, what is running, and what recently changed.
In this workflow, Cloudflare knows how the public hostname maps to its routing rules, pools, origins, and edge controls. Anyshift connects that entry point to the cloud, Kubernetes, application, and datastore resources behind it.
To avoid redirecting checkout into the same failure, authenticated queries to Anyshift compare what sits behind checkout-primary and checkout-fallback. Their results are summarized in an impact review for a Cloudflare Worker. The review shows that both origins lead to the failed checkout-session-cache, so switching origins would keep checkout on the same broken dependency.
In this scenario, Anyshift recommends three actions: reject the failover because it would fix nothing, bypass both backends for /checkout, and wait for verified recovery.
After approval, the Worker serves a controlled degraded-mode response (such as “Checkout temporarily unavailable”) without contacting either backend. The Workflow restores normal traffic after Anyshift confirms recovery.
What Anyshift checks before the fallback is approved
Before the fallback is approved, authenticated, read-only queries to the Anyshift Graph API collect the evidence needed to compare both routes. The checks below show the inputs and outputs used to build the assessment sent to Cloudflare.
What is failing?
The health monitor marks checkout-primary unhealthy but cannot identify the downstream cause. This query finds infrastructure shared by recent checkout failures:
Anyshift Graph API input
SELECT * FROM common_cause
WHERE namespace = 'checkout' AND since = '24h'
LIMIT 5Anyshift Graph API output (cropped)
{
"intent": "commoncause",
"commonCause": {
"failingPods": 4,
"events": 7,
"byWorkload": [
{ "name": "checkout-api", "affected": 4 }
],
"byDatastore": [
{ "name": "checkout-session-cache", "affected": 4 }
]
}
}The result gives the next query its target: checkout-session-cache.
Would the fallback leave the failed datastore?
Once the failed datastore is known, two path queries compare what the primary and fallback pools reach:
Anyshift Graph API inputs
SELECT * FROM path
WHERE from = 'checkout-primary'
AND to = 'checkout-session-cache'
AND scope = 'operational';
SELECT * FROM path
WHERE from = 'checkout-fallback'
AND to = 'checkout-session-cache'
AND scope = 'operational';Anyshift Graph API outputs (cropped)
{
"primary": {
"found": true,
"path": [
"checkout-primary",
"origin-a",
"demo-alb-a",
"checkout-api",
"checkout-session-cache"
]
},
"fallback": {
"found": true,
"path": [
"checkout-fallback",
"origin-b",
"demo-alb-b",
"checkout-api",
"checkout-session-cache"
]
}
}The pools use different origins and load balancers, but both paths converge on checkout-api and the failed checkout-session-cache. The fallback changes the address, not the failure path, so the assessment rejects it.
How the checkout assessment reaches the Cloudflare Workflow
The implementation sends the checkout assessment to an authenticated Worker endpoint. The Worker validates it and starts a Workflow with the evidence and proposed response.
HTTP handoff to the Cloudflare Worker
curl --request POST "$WORKER_URL/reviews" \
--header "Authorization: Bearer $CONTROL_TOKEN" \
--header "Content-Type: application/json" \
--data-binary @review.jsonStarting the bound Cloudflare Workflow
const review = await request.json();
await env.IMPACT_REVIEW.create({
id: review.reviewId,
params: review,
});The Workflow then follows four steps:
1. Record and approve: the Workflow records the assessment and waits for operator approval.
2. Protect checkout: after approval, the Worker serves the temporary /checkout response (so neither unhealthy origin is contacted).
3. Keep the state consistent: a Durable Object records whether the fallback is active (so every request follows the same mode).
4. Evaluate recovery: the Workflow waits for Cloudflare health checks, a canary request (a controlled request through the recovered origin), and fresh Anyshift evidence.
Is the original route ready to receive traffic again?
After engineers repair the failed checkout-session-cache, checkout-primary starts passing health checks again. Cloudflare must now decide whether it is safe to stop serving the temporary Worker response and send /checkout traffic back to the primary origin. A new Graph API request checks whether checkout-api is still producing dependency failure events, then sends the result to the waiting Workflow.
Anyshift Graph API input
SELECT * FROM failures
WHERE target = 'checkout-api' AND since = '5m'
LIMIT 10Anyshift Graph API output (cropped)
{
"intent": "failures",
"failures": {
"total": 0,
"recent": []
}
}This is Anyshift's contribution to the recovery decision. It reports no recent dependency failures, but it does not prove recovery by itself. When this result agrees with Cloudflare's health checks and a successful canary request, the Workflow restores normal traffic.
Result in Cloudflare
The completed run shows the full Anyshift review under Input params, the combined recovery result under Output, and the durable Cloudflare execution history.
What this integration shows and where it goes next
In this article, we showed how Anyshift adds production context to Cloudflare traffic decisions, while Cloudflare executes and records the response. Together, they let agents reject unsafe changes, keep approved responses bounded, and restore traffic from fresh evidence.
The same pattern can support:
- Failover and regional steering: verify that a backup pool, region, or cloud does not share the failed dependency.
- Protection and edge changes: preserve WAF, Access, TLS, and rate-limit controls across Worker, origin, or cache changes.
- Recovery and rollback: record the decision evidence, involve the right owner, and reverse the change if failures return.
If your team uses Cloudflare and wants production context behind traffic and edge changes, show us the decision you want to make safer.
