Varnish grace mode lets a Hyva Magento storefront serve a slightly stale cached page while it fetches a fresh one in the background, so a cache expiry or a slow backend never makes a shopper wait. The catch is that Magento’s default tag-based purges are hard, which bypasses grace entirely.
Grace mode is one of the most effective and least understood resilience features in a Magento cache stack. Done right, it absorbs traffic spikes and backend hiccups invisibly. This guide covers how grace works, Magento’s defaults, why a standard purge defeats it, and how soft purge brings the two together. For the full cache picture, see our guide to Magento full page cache and Varnish on Hyva.
What grace mode actually does
When a cached object passes its TTL, the naive behavior is to block the request while Varnish fetches a fresh copy from Magento. On a busy store, that means every expiry is a small stall, and under load those stalls pile up.
Grace mode changes this. Varnish keeps an object for a grace window after its TTL expires, and when a request arrives for a stale-but-in-grace object, Varnish serves the stale copy immediately and triggers a background fetch to refresh it. The shopper gets an instant response; the next shopper gets the fresh page. This is stale-while-revalidate, and it is configured with beresp.grace in the backend response, with vcl_hit checking whether the object is still within TTL + grace. Varnish’s own grace mode guide explains the mechanics.
There is a second, bigger payoff: when the backend is unhealthy, grace can serve stale content far longer, keeping the storefront up even while Magento is struggling. A store that would otherwise show errors instead serves slightly old pages until the backend recovers.
Magento’s defaults
Magento ships with grace configured. The default TTL is 86400 seconds (24 hours), and the default grace period is 300 seconds, set in the admin under the Full Page Cache section. So by default, Varnish will serve a stale object for up to 5 minutes past its TTL while refreshing it. Adobe’s advanced Varnish configuration documentation covers the grace setting and the VCL that applies it.
That 300-second default is conservative. For a high-traffic store, a longer grace window gives more resilience against backend slowness, at the cost of potentially serving older content for a bit longer. The right value depends on how fresh your content truly needs to be versus how much you value never making a shopper wait. MGT-Commerce’s guide to Varnish grace mode on Magento 2 walks through tuning it for traffic spikes.
| Setting | Magento default | What raising it does |
|---|---|---|
| TTL | 86400s (24h) | Longer time before an object needs refreshing |
| Grace period | 300s | Longer window to serve stale while revalidating |
| Backend-unhealthy grace | Extended | Keeps the store up longer when Magento struggles |
Why a normal purge defeats grace
Here is the trap. Grace only applies to objects that expire naturally. When you issue a hard purge or ban, the matching objects are removed from the cache immediately, so there is nothing left to serve stale. Grace never gets a chance.
And Magento’s default invalidation is exactly that: a hard operation. When content changes, Magento sends an HTTP PURGE carrying an X-Magento-Tags-Pattern header to every cache host, and the generated VCL turns that into a ban against the cache tags Magento attached to the objects. A ban is a hard removal. So the moment you save a product, the pages tagged with it are gone from cache, not expired-with-grace, and the next shopper pays the full backend render, the same cold-cache cost our guide to full page cache warming on Magento and Hyva addresses.
This is fine for a low-frequency change. It becomes a problem when invalidations are frequent or happen under load, because each one drops pages that then have to be rebuilt synchronously. A catalog import that touches thousands of products, or a pricing job that runs during peak hours, can purge large swaths of the cache at exactly the wrong moment, turning a routine update into a performance incident.
Soft purge: expire instead of remove
The fix is a soft purge. Instead of removing an object, a soft purge re-arms it: it drops the TTL to zero so the object is considered stale, but keeps the object around for its grace and keep windows. The result is that a soft-purged object is immediately served stale while a fresh copy is fetched in the background, exactly like a natural expiry.
The mechanics, at the Varnish level:
- Varnish’s purge VMOD offers a soft purge that re-arms the object with new TTL, grace, and keep values rather than deleting it. Setting all three to zero makes it equivalent to a hard purge.
- It must be called from both
vcl_hitandvcl_missso every variant of an object is handled. - With surrogate-key invalidation, the open-source xkey vmod provides a soft-purge function so you can soft-purge by tag rather than by URL, which maps naturally onto Magento’s tag-based model.
So the pattern to get stale-while-revalidate on invalidation is: tag objects with surrogate keys in the backend response, keep beresp.grace set, and replace the hard ban in your VCL with a soft expiry of the matching keys. Then a product save expires the tagged pages instead of deleting them, and shoppers keep getting instant responses while Varnish refreshes in the background. Test any such VCL change with Varnish’s test harness before deploying, because getting invalidation subtly wrong is worse than the problem you started with.
The pitfalls to plan for
Three issues bite teams working on Magento Varnish invalidation, and all of them matter more once you are tuning grace and soft purge:
- Errors break tag bans. If a fatal error occurs before Magento sets the tag header, the page can be cached with no
X-Magento-Tags-Patternat all, which means no purge ever matches it and it stays cached until TTL. Watch for pages that never seem to update. - Multi-store needs host-aware invalidation. A naive ban can match identical product IDs across stores, purging Store B when you changed Store A. Host-scoped bans using an
X-Hostheader fix this. Our guide to running multiple stores on one Magento install covers the multi-store architecture this sits inside. - ACL mismatches cache forever. If the machine Magento runs on is not in Varnish’s purge access list, its purge requests get a 405 and the cache never clears. A store that “won’t update no matter what” is often this.
Why this matters more on Hyva
A Hyva store is built for speed, and its pages are overwhelmingly public and cacheable because private data loads client-side through customer-data sections. That makes Varnish grace mode especially effective: almost everything the shopper sees can be served stale-while-revalidating, so cache expiry and backend slowness are invisible. Grace is also a resilience layer for traffic spikes, which our guide to scaling Magento for flash sales and product drops covers, and it protects the Time to First Byte that our guide to reducing Magento time to first byte is all about. For the full platform, see our Magento development services.
How managed platforms handle it
Stale-while-revalidate is a general CDN concept, and managed platforms give it to you without VCL:
- Teams on Shopify development rely on Shopify’s managed CDN, which handles caching and revalidation for them.
- BigCommerce development and Shopware development abstract the cache layer to varying degrees, with less direct control than self-hosted Varnish.
On self-hosted Magento you own the cache, which means you can tune grace and soft purge precisely for your traffic and content, and you have to. The team at Bemeir configures this on production Hyva stores, and our technology partners include the hosting and CDN layers it runs on. Learn how we work about Bemeir, and see our Hyva development services for the fast storefront grace mode keeps online.
FAQ
What is Varnish grace mode?
Grace mode lets Varnish keep a cached object for a window after its TTL expires and serve that slightly stale copy immediately while fetching a fresh version in the background. The shopper gets an instant response, and the cache refreshes behind the scenes. It also lets Varnish serve stale content longer when the backend is unhealthy, keeping the store up.
What is Magento’s default Varnish grace period?
300 seconds, on top of a default TTL of 86400 seconds (24 hours), set in the admin under the Full Page Cache section. So Varnish serves a stale object for up to 5 minutes past its TTL while revalidating. You can raise the grace period for more resilience on a high-traffic store.
Why does my Magento cache purge make pages slow again?
Because Magento’s default invalidation is a hard ban against cache tags, which removes the matching objects from Varnish entirely. Grace only applies to objects that expire naturally, so a hard purge bypasses it and the next shopper pays the full backend render. A soft purge expires the object instead of removing it, preserving grace.
What is a soft purge in Varnish?
A soft purge re-arms a cached object with a new TTL, grace, and keep rather than deleting it. Dropping the TTL to zero marks it stale so it is served stale-while-revalidating, exactly like a natural expiry. It must be called from both vcl_hit and vcl_miss, and the xkey vmod lets you soft-purge by tag to match Magento’s model.
Why is grace mode especially useful on Hyva?
Because a Hyva storefront is mostly public, cacheable pages, with private data loaded client-side through customer-data sections. That means nearly everything can be served stale-while-revalidating, so cache expiry and backend slowness stay invisible to shoppers, and grace acts as a resilience layer during traffic spikes.
Resilience you configure once and feel every day
Grace mode and soft purge are the difference between a storefront that stalls on every cache expiry and one that stays fast through expiries, invalidations, and backend hiccups. The default grace is a start; tuning it, and moving from hard bans to soft purge, is where the resilience really comes from. Bemeir is the USA’s first Hyva Gold Partner and an Adobe Commerce shop that configures caching for stores that cannot afford to be slow. If your storefront stalls on every product save or buckles under a traffic spike, grace and soft purge are usually the missing piece, and tuning them is one of the highest-return cache changes a busy Magento store can make.
