How it works

This page explains the mechanics. You do not strictly need it to use Cache Rocket, but understanding the run loop makes every setting on the warmer form obvious instead of mysterious.

The life of a warm run#

A warmer is a saved configuration, not a running process. It sits idle until something starts a run. When a run begins, this is the sequence:

1. 1

   Seed the queue

   Cache Rocket takes your entry URLs and, if enabled, expands any sitemaps it finds. These become the first items in the crawl queue.

2. 2

   Check permission

   Every URL is checked against your verified hostnames. Anything pointing at a domain you have not proven you own is dropped before a single request is sent.

3. 3

   Request a URL

   Cache Rocket fetches the URL over HTTP with your configured headers, cookies, and user agent, and records how long the response took. This is the first load.

4. 4

   Request it again

   Immediately afterwards it fetches the same URL a second time. That is the warm load. Because the first request filled the cache, the second should be dramatically faster.

5. 5

   Discover more URLs

   Links found in the HTML are added to the queue, as long as they stay on a verified hostname, are not excluded, and are within your depth limit.

6. 6

   Repeat within the limits

   The queue is worked through at no more than your max URLs per minute, and stops when the queue empties or a plan limit is reached.

7. 7

   Record and notify

   Results feed Cache health. If the run failed or errored heavily, your configured Alerts fire.

The double fetch, and why it matters#

Fetching each URL twice is the single cleverest thing Cache Rocket does, and it serves two purposes at once.

The first purpose is warming. The first request pays the cold-start penalty — it forces your origin to build the page and every cache in front of it to store the result. Cache Rocket volunteers to be the visitor who waits, so a real person does not have to.

The second purpose is proof. By timing both requests, Cache Rocket can show you the difference. A first load of 1,800 ms followed by a warm load of 90 ms is unambiguous evidence that the cache filled. If both numbers are slow, your caching is not working and warming alone will not save you — which is itself extremely useful to know.

How URLs get discovered#

A warmer finds work in three ways, and they stack together:

Entry URLs

The starting points you type in by hand. Always used. For many sites a single entry URL — the homepage — is enough.

Sitemaps

If Include sitemaps is on and an entry URL points at an .xml sitemap, every URL listed inside is added. This is the reliable way to cover large sites, because your CMS maintains the list for you.

Link following

Cache Rocket reads the HTML it fetches and queues the links it finds, going no further than your depth setting allows. This catches pages that are not in any sitemap.

Depth is measured in hops from an entry URL. Your homepage is depth 0. Anything linked directly from it is depth 1. Anything linked from *those* pages is depth 2, and so on.

depth 0   https://example.com/                     ← entry URL
depth 1   https://example.com/blog/
          https://example.com/pricing
          https://example.com/about
depth 2   https://example.com/blog/warming-101
          https://example.com/blog/cdn-basics
depth 3   https://example.com/blog/author/sam

What starts a run#

If a warm schedule window is configured, scheduled auto-starts falling outside the allowed hours are skipped. Manual starts and deploy triggers still work.

The guardrails#

A cache warmer is, structurally, a polite robot that sends a lot of requests at a website. Cache Rocket takes that seriously and constrains it in three ways.

It only touches domains you own

Every hostname must be verified through DNS or an HTTPS file before it can appear in a warmer. This is not optional friction — without it, the service could be pointed at somebody else's server as a denial-of-service tool. See Hostname verification.

It respects a speed limit you set

Max URLs per minute is a hard ceiling on request rate. Set it to what your hosting can comfortably absorb *on top of* real traffic. Shared hosting might want 5–10; a well-provisioned origin behind a CDN can often handle several hundred.

It stays inside your plan limits

Your subscription caps URLs per minute, day, week, and month, along with crawl depth and the number of warmers. When a limit is reached the run stops cleanly rather than overrunning. See Plans and limits.

Where the pieces live#