Launched this week
warmup.rocks
Your cache is cold. Your visitors pay for it.
13 followers
Your cache is cold. Your visitors pay for it.
13 followers
CDN caches are per-location: a hit in Frankfurt does nothing for Tokyo. warmup.rocks requests every page of your sitemap from 42 countries, warming 90+ edge locations on any major CDN — with per-location hit-ratio reports that prove it worked.
Hey PH, Kevin here — I built warmup.rocks after my own sites kept showing 600 ms response times from regions I cared about, despite "everything cached at the edge."
The uncomfortable truth: CDN caches are per-location. Your traffic keeps caches warm exactly where your visitors already are — and cold everywhere else, including the US data centers Googlebot crawls from. A crawler or plugin can't fix that from one server.
So this requests every URL of your sitemap from 42 countries, one per edge location, and shows a per-location hit-ratio report to prove it worked.
Fastest way to see if you have this problem: run the free cache checker on your own domain.
Curious what the community thinks — and happy to nerd out on cache keys, tiered caching, or why your cf-cache-status says MISS.
Ran it on a client site and the per-location report caught a dead zone in Singapore I never would have guessed existed. Worth it just for that visibility.
@sevgivnzu Love that. A global average can look healthy while an entire region sits cold - Singapore is a classic blind spot because it's often served from a different PoP than people expect. The per-location report exists precisely for that. Thanks for running it on a real client site.
Would love to see a way to exclude URLs with certain query params or regex patterns from the warmup run, some of our paginated/campaign pages just bloat the crawl without adding real cache value.
@batuhana92994Good timing, this exact thing just went live. Project settings → Advanced setup → "Exclude URLs": substring or /regex/, one per line. ?utm_ for campaigns, /page/\d+ for pagination. Skipped in every run, so they stop eating your URL limit and traffic budget.
the per-location hit ratio reports are genuinely useful, most tools just tell you "yes it's cached" and leave you guessing. ran it on a 200-page sitemap and the dashboard showed exactly which edges were cold
@hasanvhzv That's the whole point of breaking it down per location. "It's cached" is only true at the edge that answered; the next visitor over can still be cold. Glad the 200-page run made the cold edges obvious, that's the part a global number hides.
have been waiting for something like this for ages, the per-location hit ratio reports are a really nice touch. one idea though: let me schedule recurring warmups on a cron basis so my edge stays primed automatically after deploys or content updates instead of having to trigger it manually each time.
@arasyaka31982 Good news, that's built in. Projects warm automatically on an interval you choose, and there's a deploy hook (URL or GitHub Action) to fire a run right after each deploy instead of waiting for the next tick. No manual trigger needed. Details under Schedules and Deploy hooks in the docs.
Hit ratio reports sound super useful. One thing i'd love: schedule recurring warmups on a cron so the cache stays primed after deploys or TTLs expire, instead of me remembering to re-trigger it every time.
@kazm4y6g That's covered on both fronts. Every project warms automatically on an interval you pick (down to hourly), so TTL expiry is handled without you remembering anything. For deploys there's a deploy hook: hit the per-project URL or drop the GitHub Action into your pipeline as the last step, and a run fires right after the push. Schedules and Deploy hooks in the docs have the details.