Checking cache

Checking the cache status of an object on your website can help when troubleshooting problems. You can use the web interface or the curl command (an open-source command line tool for transferring data with URL syntax from or to a server using one of many supported protocols) to check Fastly's cache nodes for a cached object, and you can use the information provided to examine the object's status, response time, and content hash.

Using the web interface

Follow the steps below to check the cache status of an object using the Fastly web interface:

  1. Log in to the Fastly web interface.
  2. From the Home page, select the appropriate service. You can use the search box to search by ID, name, or domain.
  3. Click Check Cache.

    the Check Cache window

  4. In the Full URL path field, enter the full path to the object (e.g.,

  5. Click Check Cache. The results are displayed in the Check Cache window.

    the Check Cache results

You can use this information to verify that the same copy of an object is stored on all of our servers. If the content hash is different across nodes, that usually indicates that there's a caching problem.

Using curl

The easiest way to tell if your request is caching in the Fastly network is to use the check cache feature in the Fastly web interface, but if you prefer command line utilities, you can also use one of two curl commands for debugging purposes:

Using the simple curl command

The following curl command displays the request and response headers for a given object:

$ curl -svo /dev/null

where is replaced with the full object path of the object you're testing.

For example, using curl -svo /dev/null produces something like the following section of output:

< Age: 142
< X-Served-By: cache-jfk1041-JFK, cache-ord1720-ORD
< X-Cache: HIT, HIT
< X-Cache-Hits: 1, 7

This output tells us the current age of the object in cache. It also shows shielding is enabled because two cache nodes display in X-Served-By. However, we're most interested in the output of the X-Cache header. A properly caching object displays a value of X-Cache: HIT, X-Cache: HIT, HIT, X-Cache: HIT, MISS, or X-Cache: MISS, HIT.

Using a Fastly-Debug header with curl

The Fastly-Debug header provides additional information for debugging by exposing specific information that is normally stripped when using a simple curl command:

$ curl -svo /dev/null -H "Fastly-Debug:1"

where is replaced with the full object path of the object you're testing.

For example, with optional shielding being used and a TTL set to 86400 (24 hours) using Surrogate-Control, the command curl -svo /dev/null -H "Fastly-Debug:1" produces something like the following section of output:

< Surrogate-Control: max-age=86400
< Surrogate-Key: articles articles/1 articles/2
< Age: 403
< Fastly-Debug-Path: (D cache-ord1722-ORD 1470672957) (F cache-ord1743-ORD 1470672629) (D cache-jfk1041-JFK 1470672629) (F cache-jfk1030-JFK 1470672554)
< Fastly-Debug-TTL: (H cache-ord1722-ORD 85997.246 0.000 403) (H cache-jfk1041-JFK - - 75)
< X-Served-By: cache-jfk1041-JFK, cache-ord1722-ORD
< X-Cache: HIT, HIT
< X-Cache-Hits: 1, 6

Because surrogate keys are present, the Fastly-Debug header exposes them. As with the simple curl command, this section of output tells us the current age of the object in cache. In addition, Fastly-Debug exposes specific header details to help with debugging as noted below.

Information exposed by the Fastly-Debug header

Fastly-Debug Path contains information about which cache server handles fetching and delivery of an object. The edge POP appears first in the sequence and the shield POP appears second.

  • D represents which cache by name in the edge or shield ran vcl_deliver
  • F represents which cache by name in the edge or shield ran vcl_fetch
  • the number following each specific server name is a timestamp in seconds

With shielding enabled, you should generally see four cache servers listed in this header. In rare cases where a cache server exists as both an edge and a shield within the cluster for that object, you may see two or three caches listed.

Fastly-Debug-TTL provides information on HIT and MISS timings.

  • H represents a HIT, meaning the object was found in the cache
  • M represents a MISS, meaning the object was not cached at the time of the query

For each of these timings:

  • the first number specifies the TTL remaining for the object
  • the second number specifies the grace period
  • the third number specifies the current age of the object in cache

It may take a few requests to see these numbers populate as expected because they need to either hit the cluster node or a node where the content already exists in temporary memory.

X-Served-By indicates the shield and edge servers that were queried for the request. The shield POP appears first in the sequence and the edge POP appears second.

X-Cache indicates whether the request was a HIT or a MISS for the data center.


Our shielding debugging documentation provides in depth details key to understanding the X-Served-By, X-Cache, and X-Cache-Hits headers with shielded services.

Was this guide helpful?

Do not use this form to send sensitive information. If you need assistance, contact support. This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.