---
title: Fastly-Debug-TTL
summary: null
url: >-
  https://www.fastly.com/documentation/reference/http/http-headers/Fastly-Debug-TTL
---

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

```http
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](https://www.fastly.com/documentation/guides/concepts/edge-state/cache/stale/)).
- `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](https://www.fastly.com/documentation/guides/vcl/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.