Stale Content Delivery in Nitro Route-Rule Caching

Nitro Route-Rule Cache Behavior

When utilizing swr or isr within Nuxt 3 route rules, Nitro is designed to serve a cached response while triggering a background revalidation. If the origin fails during this revalidation process, the system continues to serve the previously cached version to avoid surfacing a 5xx error to the end user.

Consistency in Multi-Replica Deployments

Because the default Nitro cache handler operates in-memory, each server process maintains its own independent cache state. In a distributed environment with multiple replicas, a failed revalidation on one node may result in that node serving a stale copy, while another node might have a more recent version or a different failure state.

There is currently no documented mechanism for a cross-instance invalidation signal or a defined maximum stale lifetime that forces a hard failure once a specific age is reached.

• How can the maximum staleness window be constrained to prevent indefinitely serving outdated content during prolonged origin failures?
• Is there a native method to synchronize cache invalidation across multiple Nitro instances without implementing an external storage provider?