Cross-CDN scheduling: failover, quality, fixed
Sites pick a supply per line among own nodes, subscribed nodes and cloud CDNs: failover, quality or fixed, with failback, minimum stay and flap freezing.
What it solves
Once a site has several supplies (your own line group, subscribed nodes, cloud CDNs), each line has to use one of them at any moment. Cross-CDN scheduling probes every supply continuously and rewrites DNS by the strategy you choose: switch away when one fails, switch back when it recovers, and freeze when switching gets too frequent.
| Strategy | What it does | Suits |
|---|---|---|
| Failover | Each line uses the first healthy supply in priority order | Sites with a clear primary and backup |
| Quality | Picks the healthy supply with the best quality score, switching only when the gain exceeds the margin | Several vendors that all work, where you want the faster one |
| Fixed | The line stays on a chosen supply; probes alert but never switch | Sites where every switch is a human decision |
Turning it on
Cross-CDN scheduling is part of the aggregated edge module (official and free in the commercial edition, not in the community edition). Bind accounts and access points first, then:
- Open Aggregated edge → Sites and lines and search for the site.
- Under Primary and backup, choose the strategy, failback mode, minimum stay and hourly switch limit, then Save.
- Candidates and health shows where each line points now and how each candidate is doing; use Switch here to switch by hand.
- Switching history explains every switch.
Main settings
| Setting | Default | What it does |
|---|---|---|
| Strategy | Failover | Failover / quality / fixed |
| Failback | Automatic | Automatic, or manual only |
| Minimum stay | 600 s | How long a recovered supply must stay healthy before traffic returns |
| Hourly switch limit | 4 | More switches than this in an hour freeze automation and alert; unfreeze by hand |
| Quality margin | 0.3 | How much better a supply must score before a quality switch |
| Quality minimum interval | 600 s | Shortest time between two quality switches |
Third-party CDNs are probed every 30 s with a 5 s timeout; 3 failures in a row mean down and 3 successes mean recovered, plus a 60 s debounce. Each line needs answers from at least 2 probe sources; with fewer it shows "not enough data" and never switches.
Typical uses
- Own line group as primary, Cloudflare as backup: choose failover; when your nodes are unhealthy the whole line moves to Cloudflare and returns 10 minutes after they recover.
- Overseas line bound to both Cloudflare and CloudFront: choose quality to use whichever answers faster and more reliably.
- A key customer's site: choose fixed so problems only alert and the on-call engineer decides.
Limits and notes
- When every supply is unhealthy nothing switches: DNS keeps its last state and an alert fires. This is usually an origin failure, and switching back and forth would only make it worse.
- Probes measure the whole path through the CDN to the origin, so an origin failure makes every supply unhealthy at once.
- Without line support at the DNS provider, only global primary/backup works.
- A frozen site needs an administrator to click Unfreeze under Sites and lines, or to keep it frozen.
- A site without a valid plan stops using the control plane's third-party CDN and subscribed supplies, and DNS returns to the site's own line group.