Yes. The HTTP stale-if-error directive, defined in RFC 5861, lets a cache return an old response when the origin returns a server error or cannot be reached, instead of passing the failure to users. It suits public, slow-changing content, and it is a poor fit for anything personal or security sensitive.
How the directive works
RFC 5861 defines two Cache-Control extensions. The one for outages is stale-if-error. It allows a cache to use a stale response when an error is encountered, such as a 500, 502, 503 or 504 response, a network segment failure or a DNS failure, rather than returning a hard error. The RFC says this improves availability.
The value is a limit in seconds on how stale the response may be. The RFC's own example is a response with max-age of 600 and stale-if-error of 1200. It is fresh for 600 seconds. After that, if the cache tries to validate and gets a 500, it may serve the old copy for another 1200 seconds. Once the response is more stale than the limit, the cache must pass the error through.
A response served this way should still look stale, with a non-zero Age header.
The RFC's second extension, stale-while-revalidate, serves a stale response immediately while checking for a new one in the background. That one hides latency. It is not an outage tool.
A header example
Cache-Control: max-age=600, stale-if-error=1200
Where it fits
| Content | Good candidate? | Why |
|---|---|---|
| Public documentation and marketing pages | Yes | Slightly old text is better than an error page |
| Product catalog or status data that changes slowly | Often | Choose the limit to match how stale is acceptable |
| Personalized pages, account data, carts | No | Stale or shared copies can be wrong or leak between users |
| Security decisions such as revocation lists, permission checks | Usually no | Old data can allow what should be denied |
| Stock levels, anything where a wrong value costs money | With care and a short limit | Decide the tolerance with the owner |
Steps to adopt it
- List the public pages and API responses that are safe to serve slightly old.
- For each, choose the longest staleness the business accepts. Write it down with the owner's name.
- Set the directive at your cache or CDN, or on the origin response, and confirm that your cache layer honors it. Support varies between implementations, so read the documentation for yours.
- Make sure responses that vary by user are marked private or not cacheable, so they never enter a shared cache.
- Test by making the origin return an error in staging and checking what users see.
- Add monitoring for how often stale responses are served. A rising number is a signal that the origin has a problem even though users are not complaining.
Related ideas
Serving stale is one form of degraded mode. Our post on designing a degraded mode covers what else to turn off. If your origin is overloaded rather than down, think about load shedding too, since a cache can also hide a problem you need to fix.
A worked example: a documentation site
This example is hypothetical. A company hosts product documentation behind a CDN. Pages change a few times a week. The origin server occasionally returns errors after deployments. The team wants visitors to see pages, not error screens, during short origin problems.
They choose these settings, written in words: pages are fresh for ten minutes, may be served stale for up to a day if the origin is returning errors, and are revalidated in the background when possible. In header form that is a max-age of 600 and a stale-if-error of 86400.
| Content type | Fresh for | Stale if error | Reason |
|---|---|---|---|
| Documentation pages | 10 minutes | 1 day | Slightly old docs are fine |
| Release notes | 10 minutes | 1 day | Same |
| Status banner | 30 seconds | 0 | Must be current or absent |
| Account dashboard | Not cached | Not cached | Personal data |
| Download metadata | 5 minutes | 1 hour | Checksums must match files |
The last row deserves attention. Download metadata that lists a file and its checksum should not drift apart from the file. A short stale window is safer than a long one, and the team should verify that both change together.
Step by step: introducing it safely
- Inventory your response types and mark each public, personal or security sensitive.
- Decide the staleness limit for each public type with its owner, and write it in a table like the one above.
- Set cache headers at the origin, so the intent lives with the application code and travels with it.
- Confirm your CDN or cache respects the directive. Read its documentation, because support and defaults vary.
- Make sure personalized responses carry headers that keep them out of shared caches, and test that two different users never see each other's content.
- In staging, make the origin return an error and request a page from the cache. Check that a stale copy is served and that the Age header is present.
- Record the number of stale responses served, and alert when it climbs.
Security considerations
Serving old content is not free of risk. A stale copy of a page that contained a vulnerability fix, a corrected link or a revoked download could keep circulating. If you have just published a security correction, purge the cache for the affected paths. Also be careful with error responses themselves: the RFC says the directive applies when an error response such as a 500 or 502 is received, but an error page should not be cached as though it were content.
Redirects and authentication flows deserve a second look. A cached redirect to a login page can cause loops, and a cached response that depends on a cookie can leak. When in doubt, leave it out of the shared cache.
Where it fits in a continuity plan
Think of stale serving as the cheapest layer of degraded mode. It needs no new capacity and no change in architecture. It does not replace redundancy or backups. Use it for the public face of your service while the real fixes happen.
Try it yourself
Open the vulnerability management demo and look at how items are tracked with a state. Consider how a stale cache could make a fixed issue look unfixed to a visitor, and why you purge after security fixes.
Click through it at your own pace, or open it full screen.
Quick check
Does stale-if-error fix an origin outage?
No. It buys time for content that was already cached. New or uncached requests still fail, and you still need to repair the origin.
Is it safe for logged-in pages?
Generally not. Keep per-user responses out of shared caches and decide separately what a signed-in user should see when the origin is down.
How do I choose the stale limit?
Ask the content owner how old is acceptable, then pick the shortest window that covers a typical origin incident. A day is common for documentation, minutes for anything near real time.
Sources
Last reviewed: 19 October 2026.
