---
title: beresp.ttl
summary: null
url: >-
  https://www.fastly.com/documentation/reference/vcl/variables/backend-response/beresp-ttl
---

**Type:** RTIME  
**Access:** can be read and set, but not unset

**Available in:** fetch

Maximum amount of time for which the object will be considered fresh in the cache. By default, the value of  `beresp.ttl` [will be parsed](https://www.fastly.com/documentation/guides/concepts/edge-state/cache/cache-freshness) from the `Surrogate-Control`, `Cache-Control`, `Expires`, and `Age` headers received from the backend. Setting this variable takes precedence over those headers.

Conversely, setting caching headers in `vcl_fetch` will not affect `beresp.ttl` because the value of `beresp.ttl` is derived from the headers only once, before `vcl_fetch` is executed.

Once the TTL is reached, if the object has not been evicted or purged, it will become [stale](https://www.fastly.com/documentation/guides/concepts/edge-state/cache/stale).

## Multi level caching with Age

If you have multiple levels of caching, setting `beresp.ttl` explicitly can result in content staying in cache longer than you expect. This often occurs when making use of Fastly's [shielding](https://www.fastly.com/documentation/guides/concepts/shielding/) feature or if your backend server is serving content that has already spent time in a cache. 

The `Age` header is used by servers to communicate to a client how long the content has spent in cache, and if the client is also a cache, it can take this into account when calculating a TTL. This behavior is built into [the way Fastly calculates cache TTL by default](https://www.fastly.com/documentation/guides/concepts/edge-state/cache/cache-freshness). However, if you set `beresp.ttl` explicitly, you must do this calculation if you want to respect the `Age` header.

To do so, whenever you set `beresp.ttl`, subtract any existing Age:

```vcl context="sub vcl_fetch { ... }"
set beresp.ttl = 3600s;
set beresp.ttl -= std.atoi(beresp.http.Age);
```