Templates / Cache warm-up
Warming a cache before anyone needs it
The first visitor after a purge pays for the rebuild. Warming on a schedule moves that cost to a machine that does not mind waiting.
The recipe
- Request
- GET https://{{domain}}/
- Schedule
- Every 30 minutes (*/30 * * * *)
- Timeout
- 30s
- Attempts
- 3
- Counts as success
- 2xx
You supply
- Your domain
- example.com
Host only — no https:// and no trailing slash.
Why this job exists
Caches are emptied more often than people expect: on every deploy, when a TTL lapses, when a purge fires after a content change, when the edge evicts a cold entry to make room. Each of those leaves the next request to do the expensive work — render the page, run the queries, wait on an upstream API — while somebody watches a blank screen.
On a busy site this is invisible, because the rebuild happens within seconds of a purge and one unlucky request absorbs it. On a quiet site, or in a region that gets little traffic, cache entries expire before they are used again, and a meaningful share of visitors get the slow path. Edge caches are per-location, so a site with global traffic has many caches, most of them cold.
A scheduled request keeps the entries you care about warm. It is unglamorous and it works.
Setting it up
The recipe requests the homepage on a half-hour cadence, which fits the common case of a site whose front page aggregates content. Point it at whatever is both expensive and important — a search index page, a heavy dashboard, a pricing page — rather than automatically at /.
For several pages, create one job each rather than one job that fetches many. Separate jobs give you separate history and separate alerts, so a slow product page is distinguishable from a slow homepage rather than averaged into one number.
Checking it actually works
- Look at the response time in the run history. Warm requests should be fast and consistent; a sawtooth means the cache is expiring between runs.
- Check your CDN’s cache-status header if it exposes one — most report HIT or MISS, which is a direct answer.
- Set the cadence below your TTL. Warming every thirty minutes against a fifteen-minute TTL leaves half the window cold.
Where it goes wrong
Warming one edge location
A request from one place populates the cache at one point of presence. Visitors elsewhere still get a miss. This helps most on single-origin caches and application-level caches, and least on a globally distributed CDN.
Polluting your analytics
A request every half hour is a bot visit, and server-side analytics will count it. Filter by user agent, or accept a known constant in the numbers.
Warming a page that varies per user
If the response depends on a cookie or a session, the entry you warm is the anonymous variant and may not be the one users hit. Warm pages that are the same for everyone.
Questions
Is this better than raising the TTL?
A longer TTL is simpler and free — try it first. Warming is for when you need both freshness and speed, where a long TTL would serve stale content.
Can I warm after a deploy instead?
Yes, and you should — call the same URLs from your deploy pipeline. The schedule covers the evictions that do not correspond to a deploy, which is most of them.
Does this help Core Web Vitals?
It can improve TTFB for the visitors who would have hit a cold cache. Since field data is collected from real users, removing the slow tail is exactly what moves the percentiles.
Running it here
This is a preset in the product, not an illustration. Pick it in the dashboard, fill in the one value above, and the job is created, scheduled and enabled — with retries, a record of every run showing status, latency and response, and an alert the first time one fails. Secret values are encrypted at rest and never rendered back.
The free plan runs 3 jobs hourly and needs no card. Where a recipe wants a finer cadence than your plan allows, it is slowed to the fastest schedule you are permitted rather than rejected.