Schedules & intervals
The right interval depends on one thing: how long your CDN keeps entries alive. Warm slightly more often than your cache expires, and every visitor gets a HIT.
Match the interval to your TTLs
Find the edge TTL your pages are cached with — the s-maxage /
Cloudflare-CDN-Cache-Control value or your CDN's Edge Cache TTL rule —
and schedule warming at roughly half that value:
| Edge TTL | Suggested interval |
|---|---|
| 30–60 minutes | Every 30 minutes (Summit) |
| 2–6 hours | Every 1–3 hours |
| 1 day or longer | Every 3–6 hours |
Why half? Cache entries can be evicted before their TTL when a colo is under memory pressure — rarely-requested pages go first. Warming twice per TTL keeps long-tail pages alive even through evictions.
Hourly is the sweet spot for most sites
If you're not sure, warm hourly. It's frequent enough to survive evictions and TTL expiry on typical configurations, and once caches are warm the runs barely touch your origin — most requests are answered at the edge.
After deploys and purges
Deploys and cache purges reset your edge cache worldwide. Trigger a manual run right after (dashboard → Warm now) so caches refill in minutes instead of waiting for organic traffic. If your deploy pipeline can send an HTTP request, run the warm-up as the last deploy step.
Per-plan minimum intervals
| Plan | Minimum interval | ≈ edge warm-ups per month |
|---|---|---|
| Pebble | every 3 hours | ~0.4M |
| Boulder | every hour | ~2M |
| Summit | every 30 minutes | ~8M |
More often isn't always better. Warming much faster than your TTL expires only re-fetches pages that are already HITs. Spend the frequency budget where it counts: on short TTLs and large URL sets.
Origin load
A warming run touches your origin roughly once per URL — the first request per location is a MISS that fills the cache; with tiered caching, most locations are then filled from upper tiers rather than from your origin. Requests are paced, so even large runs won't spike your origin.
Next: Analytics & WAF filtering →