The amount of time (in seconds) a response has been cached (in all nodes).

Fastly reads this header from responses. It is defined by an external standard.

When a resource is fetched from a backend server, Fastly will use the Age header as a factor in determining the freshness of the object and therefore the value of beresp.ttl in VCL.

For example, if a resource is served with the following response headers:

Cache-Control: max-age=30
Age: 10

then Fastly will set besresp.ttl to 20 (30-10), and record the Age header as part of the cached object. A request received 8 seconds later for the same resource would see a cache hit with an obj.age of 18 and obj.ttl of 12.


When a resource has passed its TTL and is therefore stale, Fastly will attempt to revalidate it if the resource includes a Last-Modified or ETag header. If the response to a revalidation request is 304 Not Modified, we will update the stored object's TTL, and reset the Age to the value included in the revalidation response, or zero if there is no Age header on the new response.

When stale content is served from cache, the value of Age may be greater than the value of the cached object's TTL.

Expires-based freshness

When the TTL of a resource is determined by an Expires header, Fastly will initialise the cache object's Age to zero, regardless of the value of the Age header on the backend response.