Every cache’s worst hour is its first: launch traffic, sale-day surges and freshly failed-over regions all arrive to find the edge empty, and the miss storm lands on origin exactly when stakes peak. Warming, deliberately prefilling caches before demand, is the fix, practiced with more folklore than method.
When warming genuinely pays
Warming needs a predictable object set and a known event: the sale catalog before the sale, the patch before patch day, the failover region’s hot set before (or immediately upon) failover, the new market’s assets before the marketing launch. Warming the unpredictable long tail is bandwidth spent on guesses; warming the measured head of your popularity curve (you have it, from the fragmentation article’s analysis) is buying your launch-hour hit ratio in advance.
The mechanics that matter
Warm through the same path users will hit, correct hostnames, correct headers including the capability classes your keys vary on, or you will warm variants nobody requests. Respect the topology: warming the shield tier gives every edge a fast local miss, warming every POP directly costs a multiple more and needs geographic request distribution to reach them (anycast will happily send all your warming to the nearest POP). Rate-limit against your own origin, jitter the schedule, and remember request coalescing is doing the same protective work during warm-up that it does in stampedes.
The failover-warming variant merits its own runbook page because timing inverts: you cannot warm before an unplanned failure, so the play becomes warm-on-trigger, an automated job that begins prefilling the surviving or newly-promoted path’s hot set the moment failover fires, racing the user traffic rather than preceding it. Combined with the survivor-sizing arithmetic from the multi-origin article and grace-mode staleness absorbing the first minutes, warm-on-trigger converts failover’s cold-cache latency spike from an hour-scale event into a minutes-scale one. Estates that rehearse failover (this series will not stop saying it) should time their warm-on-trigger job as part of the drill; the number belongs next to the DNS decay curve in the resilience report.
The backfires
Warming that evicts: caches are finite, and aggressively prefilling the tail can push out the genuinely hot present. Warming wrong variants (missed Vary dimensions) that never serve. Warming that masks bugs, prefilled success hiding the misconfigured cache keys that will fragment under real traffic. And the organizational backfire: warming as a ritual that substitutes for fixing TTLs and purge discipline, treating symptoms at bandwidth prices.
In practice
Build the warming list from measured popularity, warm shield-first through production-identical requests, schedule with jitter inside the day before the event, and verify with hit-ratio dashboards segmented to the warmed set. Then, after the event, compare warmed versus unwarmed cohorts and keep the numbers: warming earns a permanent runbook slot only if the launch-hour delta pays for the transfer, and now you know.
Event-readiness engagements here include the warming runbook, popularity-derived lists, and the post-event cohort comparison.