Core concepts

Cache Rocket uses a small set of terms consistently across the app and these docs. Learning them once makes everything else quicker to read.

Warm and cold#

Cold

No usable cached copy exists. The next request must be rebuilt by your origin server, which is slow and expensive.

Warm

A fresh cached copy exists. The next request is served from cache, typically in a few milliseconds, without touching your application.

Warming

Deliberately requesting a URL so its cached copy is created or refreshed before a real visitor needs it.

Cold-start penalty

The extra time the first visitor after expiry waits while the page is rebuilt. Eliminating this is the entire point of Cache Rocket.

Warmers#

A warmer is a saved configuration describing what to warm and how. It is the central object in Cache Rocket; almost everything else attaches to one.

Active, and what starts a run#

Every warmer has an Active switch. Inactive warmers keep their configuration but never run — useful while setting one up, or to pause during maintenance.

An active warmer runs on its schedule, and can also be started by hand, by a deploy webhook, or by a CDN purge action.

Entry URLs#

An entry URL is a starting point for a warm run. Write it in full, including the scheme:

https://www.example.com              ← good
https://www.example.com/sitemap.xml  ← good, a sitemap
www.example.com                      ← bad, no scheme
/products                            ← bad, not absolute

Entry URLs must use a verified hostname. Most sites need only one, because link discovery and sitemaps do the rest. Add more to guarantee coverage of a section that is poorly linked from the homepage — a deep category page, a landing page reachable only from ads, or a second subdomain.

Depth#

Depth limits how many link-hops from an entry URL the warmer will travel. An entry URL is depth 0; pages linked from it are depth 1; pages linked from those are depth 2.

If you use sitemaps you often need less depth: the sitemap already lists your deep pages directly, so they can be warmed without crawling down to them.

The two intervals#

These are frequently confused, and they control different things.

Auto start interval

How often a new run begins, in seconds. 3600 means the warmer starts a fresh pass over your site every hour. This is the setting you usually want to think about.

Enqueue interval

How often URLs are re-queued within the warming cycle, in seconds. It governs the pacing of work rather than when a pass begins. The default is fine unless you have a specific reason to change it.

Pick the auto start interval by asking how long you are willing to let a page sit cold. If your CDN caches for an hour, warming every hour keeps things continuously warm. Warming far more often than your cache TTL just adds load without benefit.

Rate limits#

Max URLs per minute is the throttle, and the most important safety setting on the form, because it decides how much load warming adds to your origin.

Start low. Raise it only while watching your origin's CPU and response times. Your plan also enforces its own ceilings per minute, day, week, and month.

Hostnames and verification#

A hostname is a domain you have registered with Cache Rocket and proven you control, such as www.example.com. Until a hostname is verified, no warmer may target it.

Verification is a deliberate abuse control. Without it, anyone could point the service at a stranger's server and use it as an attack tool. Detail in Hostname verification.

Measuring the result#

First load

How long the first of the two requests took. Represents the experience of a visitor arriving at a cold page.

Warm load

How long the immediate second request took. Represents the experience of everyone who arrives after warming.

Improvement

The gap between the two. This is the concrete benefit warming delivered for that URL.

Warmth score

The share of your tracked URLs that look properly cached, based on timings and cache-related response headers.

Cold URL

A URL that stays slow even after being warmed — usually a sign it is not cacheable rather than a warming failure.

These roll up into Cache health.

Workspaces and roles#

By default everything lives in your personal account. On plans that include teams you can create workspaces (organisations) that own their own warmers, hostnames, alerts, and CDN integrations.

Members get a role — Owner, Admin, Developer, Finance, or Viewer — that decides what they can see and change. Agencies use one workspace per client. See Teams and roles.

Plans and entitlements#

• Limits — numeric ceilings, such as how many warmers you may create, how deep they may crawl, and how many URLs you may warm per month.
• Entitlements — whether a capability is available at all, such as sitemaps, custom headers, multi-region warming, GraphQL, or teams.

Fields for capabilities your plan does not include are hidden or disabled on the forms, so the interface always reflects what you can actually use. See Plans and limits.

API keys#

A public key and secret key pair authenticates machine access — the WordPress plugin, deploy webhooks, and the public API. The secret is shown once, immediately after generation, and never again. Manage them under Account → Account. See API keys.