Cron Expressions for Cache Warming: A Practical Guide

The right cache warming schedule re-warms each page just before its TTL expires: for most sites that means a nightly full warm, plus targeted runs around purge events like deployments and content updates. This guide gives ready-to-copy cron expressions for the most common scenarios, with the reasoning behind each one.

Why schedule matters

Cache warming runs consume URL quota and put a load on your server. Running too infrequently means your cache goes cold between runs. Running too often wastes quota on pages that are still warm.

The right schedule depends on your TTL, your purge frequency, and your traffic patterns. This guide covers the most common scenarios with ready-to-copy cron expressions.

Cron expression basics

A cron expression has 5 fields:

┌───── minute (0–59)
│ ┌───── hour (0–23)
│ │ ┌───── day of month (1–31)
│ │ │ ┌───── month (1–12)
│ │ │ │ ┌───── day of week (0–6, 0 = Sunday)
│ │ │ │ │
* * * * *

Common symbols:

• *: every unit
• */n: every n units
• a,b: specific values a and b
• a-b: range from a to b

Scenarios and expressions

Nightly full warm (most common)

Runs once per night, after peak traffic and before the next morning's visitors. Good for sites with a 1-hour or longer TTL.

0 3 * * *

Runs at 3:00am every day.

Adjust for your timezone: CacheBoost uses UTC. If your peak morning traffic is at 8am Paris time (UTC+2), run the warm-up at 1:00am UTC:

0 1 * * *

Every 4 hours (medium-TTL sites)

For sites with a 4-hour TTL, warm every 4 hours to ensure pages never expire without being re-warmed:

0 */4 * * *

Runs at 0:00, 4:00, 8:00, 12:00, 16:00, 20:00 UTC.

Business hours warming (SaaS / B2B)

If your traffic is mostly business hours (9am–6pm), focus warm-up runs during that window:

0 7-17 * * 1-5

Runs every hour from 7am to 5pm UTC, Monday through Friday.

E-commerce peak hours

Online stores often see peak traffic in the evening. Warm before peak and maintain through the evening:

0 17,18,19,20,21 * * *

Runs at 5pm, 6pm, 7pm, 8pm, and 9pm UTC.

After content-heavy publish days

If your editorial team publishes most content on Tuesday and Thursday mornings:

0 6 * * 2,4

Runs at 6am UTC on Tuesday (2) and Thursday (4).

Multiple times per hour (very short TTL)

For aggressive caching setups with short TTLs (5–15 minutes), warm every 10 minutes:

*/10 * * * *

Use this sparingly: it consumes quota quickly on large sites.

Before a scheduled event (one-off)

For a scheduled sale, product launch, or high-traffic event, set a one-time run:

30 8 15 6 *

Runs at 8:30am UTC on June 15th. After the event, remove the schedule or pause the boost so it doesn't run again next year.

Combining schedules

CacheBoost supports one schedule per boost, but you can create multiple boosts for the same site:

• Boost A: high-priority pages (homepage, top 50 URLs), runs every hour with 0 * * * *
• Boost B: full sitemap, runs nightly with 0 2 * * *
• Boost C: mobile user-agent only, runs after deploy via API trigger

This tiered approach ensures your most important pages are always warm without burning quota on long-tail pages hourly.

Validating your expression

Before saving a schedule, use crontab.guru to verify your expression resolves to the times you intend. Paste your expression and it shows the next 10 scheduled runs in plain English.

The schedule + deploy combination

A schedule alone isn't enough if you deploy frequently. Each deployment flushes the cache mid-schedule-window. Always pair your schedule with a deploy-triggered run via the API:

# In your deploy script
curl -s -X POST https://api.cache-boost.com/v1/boosts/$BOOST_ID/run \
  -H "Authorization: Bearer $API_KEY"

The scheduled run handles TTL-based expirations. The API trigger handles deploy-based flushes. Together, they keep your cache warm regardless of what caused the flush.