Drupal cache warming after deploys

Why Drupal cache warming after deploys matters for busy sites

A release, a configuration import or a manual cache clear empties the caches that Drupal relies on, and the first visitors to hit each page pay the cost of rebuilding it. On a quiet site this is barely noticeable. On a busy site, a launch or a post-deploy traffic spike can send many concurrent requests into pages that are all cold at once, so the slowest requests land on the people who arrive first. Cache warming is the practice of requesting critical pages and entities after a cache clear so that the rebuilt copies exist before real users arrive. Warming does not change how Drupal caches anything. It only changes when the expensive work happens and who absorbs it.

Teams usually need a warming step in three situations: high-traffic launches, post-deploy spikes on sites where most traffic lands on a few landing pages, and flushes of external cache stores such as Redis or Memcache, where every page and entity must be rebuilt from the database. The Warmer module is a contributed module from Drupal.org, not part of Drupal core, so it must be specified, reviewed and maintained like any other dependency. Confirm that the Warmer release you select supports the Drupal version in use, including the Drupal 10 and Drupal 11 combinations your site needs, and read its documentation for the crawling and queueing behavior it provides before relying on it in production.

Before you decide on warming, confirm which pages are actually slow when cold. Compare response times for anonymous and authenticated traffic after a clear in a staging environment that mirrors production, and identify the handful of URLs that carry most of the traffic. A warming list kept short and tied to those URLs is easier to schedule safely than a crawl of the whole site. Ask your partner or internal team to document which cache backends, reverse proxies and CDN layers sit in front of Drupal, because a warmer that requests pages through the wrong layer can fill the wrong cache or add load you did not plan for.

Warming options and when each fits

This table compares the main choices for a Drupal cache warming plan: which URLs to request, whether to include authenticated traffic, how granular the warming is, and when it runs. Read each row for its load, freshness and coverage trade-offs, then confirm the exact options in the Warmer version you install, since module settings differ between releases.

Decision	Option	Trade-off	When it fits
URL source	Top landing pages from analytics	Warms what real visitors request most, but misses new or rarely visited pages and needs periodic review	Content-heavy sites with stable traffic patterns and a short, known list of entry points
URL source	Main menu and footer links	Small, predictable list that covers navigation, but says little about deep content pages	Sites where most traffic enters through navigation and the menu changes rarely
URL source	Sitemap-derived list	Broad coverage of published content, but a large sitemap can create significant request volume after every release	Sites with a maintained sitemap and capacity to absorb a longer warming run
URL source	Entity lists such as taxonomy terms or recent nodes	Targets specific entities that change often, but requires a view or query to stay current	Sites where a few listing pages or recent content drive most cache misses
Audience	Anonymous traffic only	Lowest load and simplest cache keys, but logged-in editors and members still see cold pages	Public sites where most visitors are anonymous and the cache backend is shared with editorial work
Audience	Authenticated traffic included	Warms personalized variants only where the configuration allows it, which can multiply requests and storage use	Member or intranet sites with a small number of well-defined roles and measured cache hit rates
Granularity	Full-page warming via HTTP requests	Exercises the whole stack including the reverse proxy and CDN, but adds web server load and depends on the proxy accepting warmer requests	Sites with a page cache or CDN in front of Drupal where the first visitor pays the cost
Granularity	Entity-level warming	Refreshes the cached entities Drupal renders, with less web tier load, but does not fill proxy or CDN copies	Sites where Drupal's internal caches are the main bottleneck and the edge is handled separately
Trigger	After deploy	Covers code and configuration changes that clear caches, but the warming run competes with live traffic during the release window	Teams that release often and want the first visitors after a release to see warm pages
Trigger	After cache clear or purge	Responds to manual or automated cache clears, but can start unplanned load if clears happen during peak hours	Sites where clears are routine and can be gated by a rule that avoids busy periods
Trigger	Scheduled off-peak run	Keeps load predictable and separate from releases, but content changed after the run stays cold until the next pass	Sites with low overnight traffic and content that changes on a predictable cycle

How to set up cache warming after a deploy

This sequence turns cache warming from an ad hoc task into a repeatable step that runs against a known list of pages, at a rate your servers can absorb, and produces measurable hit rate and response time results after every release.

Build the list of critical pages
Start from your analytics platform to pull the most requested URLs over a period your team agrees is representative, then add the sitemap entries for landing pages, navigation targets and high-value content types. Remove URLs that are personalized, behind login or carry query parameters that do not change the page. Your content owner and a developer should sign off on the list together. Done means you have a versioned file of URLs, reviewed by both, that is short enough to finish inside your release window. The illustrative test is whether the homepage, main category pages and top articles all appear on it.
Confirm which pages are cacheable
Request each URL as an anonymous visitor and inspect the response headers and Drupal's cache behavior. Look for pages that set no-cache directives, pages whose render output varies by session or cookie in ways you did not expect, and pages that depend on user-specific blocks. Record the cache tags and max-age reported for each page. Pages that fail this check should be removed from the warm list or fixed first, because warming them only adds load without leaving a cached copy. Done means every URL on the list has a recorded cacheability result.
Install and configure the Warmer module on staging
Install the Warmer module on a staging copy of the production site with the same codebase, configuration and cache backend. Load your reviewed URL list into the module's configuration or the warmer queue, and confirm the entities or paths it targets match your list. Run it manually once against staging and check the Drupal logs for errors and the warmed count against the list length. Done means a staging run completes without errors and every URL on the list returns a cached response on a second request. Keep this configuration in version control with the rest of the deployment code.
Set a request rate the stack can absorb
Decide how many requests per second the warmer should send, starting low. Measure the web tier CPU, PHP worker utilization, database connection use and slow query log on staging while the warmer runs, then increase the rate in steps until one of those signals approaches its limit. Ask your hosting or platform team what capacity they have confirmed for the web and database tiers, since those numbers belong to your environment, not to this guide. Done means you have a recorded rate that keeps all tiers below the limits your team set, and the number is written into the job configuration.
Wire the warm run into deployment or a schedule
Add a warming step to the release pipeline after the new code is live and the cache clear has run, so the warmer fills the cache on the new build rather than the old one. Where releases are not frequent, schedule a recurring run through system cron or your container scheduler and make sure it does not overlap a previous run. Use a lock or a single-runner job so two deployments do not start concurrent warmers. Done means a release in a test environment triggers the warm step automatically and the job log shows a clean finish with the expected URL count.
Verify hit rates and response times before and after release
Capture cache hit rate and median and 95th percentile response times for the URL list in the hour before a release, using your CDN, reverse proxy or application metrics. Repeat the measurement after the warm run completes and again during the first peak traffic period. Compare the three sets of numbers and record any URLs that still miss or respond slowly. Done means you have a before and after report for each release, and any URL that stays cold is assigned to a named owner for investigation. Set the acceptance thresholds with your team before the first measured release so the review is not decided after the fact.

Security and operational risks of scheduled warmers

A warmer is an automated client that requests pages on a schedule, so it runs with the same reach as any anonymous visitor and can also stress the infrastructure. The cards below cover the access, load, caching and operational checks to settle before a warmer runs against a production Drupal site.

Keep warmer requests inside access control

A warmer should request only pages an anonymous visitor could already reach. Check that the URL list is built from published, public content and that the warmer account, if it logs in at all, holds no permissions beyond what it needs. Test with unpublished nodes, private files and restricted paths to confirm they are not warmed, cached or listed in the warmer's output. Ask whether warmed responses for protected pages could be stored by a shared cache and served to other users.

Limit load on origin and database

A warmer that requests every URL at full speed can behave like a traffic spike against PHP workers, the database and the search index. Set a concurrency ceiling and a delay between requests, and warm the heaviest entities in small batches. Run the warmer outside peak hours and watch database connections and PHP-FPM queue length during the first runs. Confirm that the schedule does not overlap with cron, queue workers or a deploy still in progress.

Avoid caching content that should not be cached

Warming writes responses into the page cache, the reverse proxy or the CDN, so a bad response becomes the one every visitor gets. Check that warmed responses carry the correct cache tags and max-age, and that personalized or session-dependent pages are excluded from the URL list. Review how error pages, redirects and 5xx responses are handled, since a warmer that caches a failure can extend an outage. Verify the warmed set against the cache policy before enabling it.

Protect warmer credentials and endpoints

Warmers often need a trigger URL, a Drush command, a token or a service account to reach the site. Store these values in your secrets manager, not in the module configuration or a version-controlled file, and rotate them when staff change. Restrict any HTTP trigger to internal networks or require authentication so outsiders cannot force cache rebuilds. Confirm that the warmer account cannot edit content or change configuration.

Log and monitor every warmer run

Each run should record its start and end time, the URL set version, the number of pages requested, the failures and the response times. Alert when a run fails, exceeds its time window or produces a rising error rate, and compare response times before and after the run. Keep the logs in the same place as your web and database logs so a warming run can be correlated with an incident. Ask the team who receives the alerts and who can pause the schedule.

Scheduling warmers safely across environments

On one web server, the main risk is a warmer run colliding with cron on the same host. Both compete for PHP workers, database connections and CPU, and a long warm can push a busy site into timeouts. Cron on a single host is usually the only other scheduler, so the fix is to keep warming and cron on distinct schedules and to stop any run that is still active before a new one starts.

Separate schedules: Keep the warmer's cron entry offset from heavy Drupal cron tasks so the two rarely start together.
Single-run guard: Use a lock or a process check so a second warm does not start while the first is still running.
Warm after the purge completes: Run the warmer only once the cache clear or tag purge has finished, not in parallel with it.
Bounded run time: Cap how many URLs or entities a run touches so it finishes inside the window you have chosen.
Log outcomes: Record start, end and failed URLs so you can tell a slow warm from a broken one.

Before go-live, confirm in a staging copy that the warmer and cron never run together under load, and that a deploy does not start a warm before the new code is in place.

With several web nodes or containers, each replica may run its own cron or its own copy of the warmer. Cron in Drupal is designed to run once per site, but a scheduled job that is not pinned to one instance can execute on every replica at the same moment. The result is duplicated load, racing purges and warm requests that hit different nodes with different PHP OPcache and local state. Serialize warming to one designated job, and make sure the purge and warm steps share one queue.

Single scheduler: Run the warmer from one scheduled job, such as one Kubernetes CronJob with concurrencyPolicy set to Forbid, rather than from every pod.
Shared lock: Protect the run with a lock held in the shared cache or database backend, so a second node cannot start a parallel warm.
Ordered steps: Complete the purge queue on all nodes before warming starts, so requests do not refill from a node that has not yet received the purge.
Replica-aware load: Warm through the load balancer or by target host with a limited concurrency level, not all URLs at once.
Lock expiry: Set a lock timeout longer than a normal run, and make sure a crashed run releases it.

Confirm with your platform team how cron jobs are pinned to a single instance and how locks behave when a node is rescheduled mid-run.

When a pipeline triggers the warm right after a release, the warm is tied to a deploy event rather than to a clock. This avoids warming the old code, but it creates a different overlap risk: a scheduled cron run may start while the deploy is still applying database updates, and the warm then executes against a half-updated site. The pipeline should only call the warmer after database updates, configuration imports and cache rebuilds have all completed, and it should wait for the scheduled job to finish or skip.

Gate on deploy completion: Trigger the warm only after drush updb, drush cim and the cache rebuild have returned success.
Pause or wait for cron: Either suspend the scheduled warm during a release window or have the pipeline wait for any active run to finish.
Idempotent triggers: Make re-running the pipeline safe, so a retried job does not start a second concurrent warm.
Timeout and failure policy: Decide whether a failed warm fails the pipeline or only raises an alert, and document the choice.
Version marker: Have the warm record the release identifier it warmed, so you can prove which build the cache reflects.

Check that your pipeline runner cannot execute two deploys to the same environment at once, and that the warm step uses the same credentials and Drush alias as the deploy.

Limits to confirm in your environment

Cache warming only helps when the warmer, the cache stack and the edge layers agree on what a warmed response is. The checks below cover the module itself, the cache backend, the layers that serve warmed pages, personalized traffic and the people who watch each run. Confirm every item in staging before a warmer touches production.

Warmer version and Drupal compatibility

Confirm which release of the Warmer module supports your current Drupal core and PHP version, and plan the upgrade path alongside your core schedule. Drupal 11 is the current major version, and Drupal 10 reaches end of life on December 9, 2026, so a warmer pinned to Drupal 10 today may need replacing during the same window. Check the module's release notes for changes to queue handling and cache APIs before each core upgrade.

Cache backend and invalidation behavior

Find out where render and page caches live, whether that is the database, Redis, Valkey or Memcached, and how each backend evicts entries. A warmer that fills a memory-limited backend can push out the very pages it was meant to protect. Confirm memory headroom, eviction policy and whether cache tags invalidate warmed entries as expected when content is edited.

CDN or Varnish layer in front

If Varnish or a CDN serves anonymous pages, a warmer that requests pages through the origin only warms Drupal, not the edge. Confirm which hostname and headers the warmer should send, whether the edge caches the response, and how purges triggered by a deploy reach the edge. Warming the origin while the edge still holds stale responses leaves visitors with the old version.

Private and personalized pages

Warmers request pages as anonymous users, so they cannot populate caches for logged-in dashboards, carts or role-specific content. Identify which routes vary by user, role, language, geography or session cookies, and decide whether any of them should be excluded from the warm list. Confirm that warmed anonymous responses never reach a page that should be private.

Run monitoring and ownership

A scheduled warmer that fails silently leaves a cold cache after every release. Decide who receives alerts when a run errors, times out or reports a high miss rate, and how long the team can respond outside business hours. Check that queue workers, cron and log retention run reliably on your servers, and that someone can pause the warmer quickly if it starts to load the origin.

Staging tests before production

Run the warmer against a staging copy with production-like content volume, cache backends and edge configuration before enabling it on production. Measure origin load, time to warm the priority list, and whether a second deploy during a warm run causes conflicts. Behavior observed in staging is the only reliable basis for the schedule and page list you adopt.

Questions teams ask before hiring help with cache warming

What does cache warming cost, and what drives the effort up?

Cost depends mostly on how many pages and entities need warming, how many environments are involved, and how the warming step connects to your CDN or reverse proxy. Effort rises with a long or messy URL list, with separate warming rules for logged-in and anonymous traffic, with each extra environment that needs its own configuration, and with CDN integration that must respect cache tags. Testing adds effort because each warmer run has to be checked against real response times. Ask for a quote that lists these items separately. Setup work is one-time, while reviewing URL lists, updating warmers when content types change, and watching queue behavior recur. DeployOpen does not publish prices, so the written scope sets the figure.

How long does a cache warming setup take?

Duration depends on site complexity rather than on the module itself. A site with a small set of stable landing pages, one environment and no CDN is simpler than a multisite estate with personalized content, several caching layers and a deploy pipeline that needs changes. Ask any partner to split the timeline into discovery, configuration, staging tests, production rollout and handover, and to state which environments and integrations each phase covers. No duration is given here because none has been researched for this topic.

What does our team need to provide for cache warming work?

Plan to supply four things early. First, access to traffic analytics so the URL list reflects pages people actually visit. Second, a list of critical pages and entities, such as navigation, top landing pages and high-traffic content types, with the owners who approve changes. Third, staging access that matches production closely enough to test warmers and measure cache behavior. Fourth, access to the deploy pipeline or release tooling, so warming can run after a deploy or cache clear in the right order. Missing any of these usually lengthens discovery and testing.

Can our own team set up cache warming using the module documentation?

Yes, a capable Drupal team can install the Warmer module and follow its documentation on Drupal.org, especially for a small site with one environment. The harder parts are choosing the URL sources, limiting load on the origin during a run, scheduling warmers safely around releases, and confirming that warmed responses are cached under the same rules real visitors receive. Teams without that experience often find the gap in testing. Ask whether an internal owner will maintain the warmer configuration after handover, because content and template changes will break the URL list over time.

Does cache warming replace proper cache invalidation?

No. Cache warming fills caches again after they have been cleared or expired, so visitors meet fewer cold responses. It does not decide when content is stale. Correct invalidation, such as purging by cache tag when an editor publishes or changes an entity, still has to be configured in the caching layer, whether that is a reverse proxy, a CDN or the Drupal page cache. If invalidation is wrong, warming will repeatedly refill outdated pages. Confirm invalidation rules first, then add warming on top of them.

Can warming overload the origin server or the database after a deploy?

It can, if the warmer requests too many pages at once. A warm-up run is effectively a burst of traffic that the web servers and database must serve. Engineers should set concurrency limits, pace requests, warm the highest-value pages first and run the job outside peak hours where possible. Check the effect on PHP workers, database connections and queue backlogs in staging before production. Confirm the exact throttling options against the Warmer module documentation for the version you run.

Does warming work for authenticated users and personalized pages?

Usually not in the same way. Warmers request URLs as an anonymous or generic client, so they fill caches that serve anonymous traffic. Pages personalized per user, or cached per role or session, need a separate decision about which variants to warm and whether that is worth the load. Ask any partner how they will test authenticated paths, and confirm which cache contexts your site uses before you commit to a warming scope.

What changes for your team after warming is in place

The main outcome is that cold-cache slowdowns after a release stop being an unplanned event. Once the Warmer module runs as a defined step after each deploy or cache clear, the pages that carry most traffic are rebuilt before users reach them, and the post-release period looks like a normal day rather than a spike in response times. The step itself becomes repeatable: the same command or cron job runs in the same order on every release, and the team can check its result instead of guessing whether the cache is hot.

Ownership changes too. Someone must own the warm URL list and the entity lists behind it, because a list nobody maintains drifts quickly as menus, landing pages and promoted content change. Decide who approves additions, who removes retired paths, and where the list lives in version control so that it ships with the code it describes. Review it on a fixed schedule, and after any major content or navigation change, by comparing it with the pages that analytics show are actually requested. Confirm with your Warmer and hosting setup how warming requests are authenticated and whether they count against your rate limits and monitoring.

Warming reduces cold-cache cost but does not remove it. Personalized pages, authenticated dashboards, pages with per-user blocks and anything marked uncacheable will still build on first request, and warming anonymous pages does nothing for them. Tell stakeholders this in writing so that performance expectations match what the work delivers, and measure the remaining cost on those pages separately. Where that cost matters to the business, the answer usually lies in caching design or rendering changes rather than in a longer warm list.

How DeployOpen works on this

DeployOpen plans and builds Drupal cache warming inside infrastructure you control, starting from a written scope that names the pages, entities and schedules to warm. Each step ends with tested behavior, documentation and a handover your own team can run after the engagement closes.

How we scope

We list the URLs, entity types and languages that must be warm before traffic returns after a release.
We map which cache clears and deploy steps trigger a warm, and which should never trigger one.
The written scope states the cache backend, web server and CDN layers the warming must work alongside.

How we build

We configure the Warmer module and its warmers for the agreed page and entity list, with throttling set to protect the origin.
We wire warming into the deploy pipeline so it runs after cache rebuilds, not during database updates.
We test warm runs against a staging copy with cache hit ratios measured before and after each change.

How we hand over

You receive the warmer configuration, schedule definitions and the deploy hook as versioned code in your repository.
Runbooks cover how to pause, rerun or narrow a warm when the origin shows load or errors.
Your team walks through a supervised warm run so the procedure is practiced before the engagement ends.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, including reviews after Drupal core or Warmer module updates.
Ask for a quote based on the written scope, which sets the effort for build, handover and any retainer.