1. Home
2. Reference documentation
3. VCL reference
4. Variables in VCL
5. Backend connection

RTIME, can be read and set, but not unset.

Available inpassmiss

The amount of time Fastly should wait for a backend server to deliver an entire object, a single object segment (if segmented caching is enabled), or a single ESI include. The timer begins after the connection to the backend has been established and the request has been sent, and runs until the last byte has been received.

The timeout may be set to any value between 0 and 365d. By default, the timeout is disabled. A value of 0 disables the timeout. While the timeout can be specified in milliseconds, millisecond accuracy is not guaranteed.

If the timeout is triggered, Fastly will create an error object and invoke vcl_error with obj.status set to 503 and obj.response set to "fetch timeout". Learn more about errors.

Effects of shielding and clustering

If clustering or shielding are enabled, the request will pass through more than one Fastly server before it is sent to the origin.

In those cases, the fetch timeout may be silently increased by a small amount in order to allow for internal processing time.

Best practices

It is important to set a fetch timeout value that is appropriate for the size of the object being fetched and the performance of the backend server. Using pattern matching on the path can be used to set a lower fetch timeout for smaller objects and a larger fetch timeout for larger objects. For example:

sub vcl_miss {
  if (req.url.path ~ "\.m3u8$") {
    set bereq.fetch_timeout = 2000ms;
  } else if (req.url.path ~ "\.mp4$") {
    set bereq.fetch_timeout = 10000ms;
  } # else unset for all other object types
}

To allow for spikes in latency and varying origin performance, a timeout of less than one second is not advised.