Hi Fastly Community,
We are thrilled to announce that stale-if-error is now available on Fastly Compute!
Stale-if-error is an HTTP Cache-Control directive that acts as a safety net for your website. Its primary purpose is to improve your site’s resilience and availability by instructing a cache to serve a stale, or expired, version of a resource when your origin server is unreachable or returns an error. Instead of a user seeing a broken page, they see cached content while you fix the root cause.
Here is a breakdown of how this new capability behaves within Fastly Compute and how you can start leveraging it:
How It Works
When your sandbox sends a request to a backend, it will check if a cached response is available and within its stale-if-error period. The default period is automatically set based on the Cache-Control or Surrogate-Control headers of the response, but you can also explicitly override it using an after_send hook.
If a cached response is available, the sandbox is obligated to attempt revalidation. If revalidation fails, the sandbox can elect to use the stale-if-error response instead.
Handling Origin Failures
Compute handles different types of origin failures in the following ways:
-
Unreachable or Sick Origins: If your origin is down or failing health checks, the platform generates a SendError under the hood, but the sandbox receives the stale response by default. If you want to record the error or selectively propagate it, you can easily access the underlying failure by calling get_masked_error() on the response.
-
5xx HTTP Responses: By default, if Compute successfully gets an HTTP response from the backend—even if it is a 5xx error—that response is provided to the sandbox. To serve a stale response instead of the 5xx error, you can use an after_send hook to check if the error is a 5xx and if stale_if_error_available() is true, allowing you to reject the 5xx and serve the stale content.
Seamless Request Collapsing
Stale-if-error is fully integrated with request collapsing. If the leader of a request collapse chooses to use a stale-if-error response, all followers of that request collapse will also receive the stale response. This happens even if the follower is running an older SDK version that doesn’t explicitly support stale-if-error. Additionally, while the leader has access to the full error object from the failed revalidation, followers will receive a simplified SendErrorCause::RequestCollapse error.
Prerequisites and Limitations
Before you get started, please note the current requirements:
- Synchronous API Only: In Compute, stale-if-error is supported exclusively via the synchronous Request::send API, as send_async is not compatible with guest caching.
We look forward to your feedback. Comment or start a conversation below.