Fastly-Debug-TTL

Provides timing information for cached resources.

Fastly writes this header into responses. It is proprietary to Fastly.

When Fastly-Debug is present in a request, this header is attached to the response and contains information on various timings.

Fastly-Debug-TTL: H cache-jfk1026-JFK 41733294.335 864000.000 2273

The syntax is:

{cacheStatus} {serverIdentity} {remainingTTL} {staleIfErrorTTL} {age}

cacheStatus: Whether or not the object was found in cache. H for hit, M for miss. "Hit" in this simplified classification includes all responses where a request was not forwarded to origin.
serverIdentity: The value of server.identity.
remainingTTL: The amount of time in seconds for which the object will remain fresh in the cache (see obj.ttl).
staleIfErrorTTL: The amount of time in seconds for which the object will be served stale if no backends are available (see staleness and revalidation).
age: The number of seconds for which the object has been in cache.

WARNING: remainingTTL and staleIfErrorTTL are only available when the server handling the request has the object in its own local cache. Otherwise those values will be shown as -. This is typically the case when a cache hit results from clustering, where the request has been forwarded from the server that initially handled it, to the one that has the item in cache. As a result it may be necessary to fetch the URL you are testing repeatedly until you see those values populated.

User contributed notes

BETA

Do you see an error in this page? Do have an interesting use case, example or edge case people should know about? Share your knowledge and help people who are reading this page! (Comments are moderated; for support, please contact support@fastly.com)