How to flush the Fastly cache


To purge all cached assets from the CDN layer sitting in front of your site.


You will need:

  • To have Fastly cache running in front of your site
  • The ability to run curl from your local terminal,
  • Working access to the platform command for your project
  • Read access to the Variables on your project through the web console.


For most Enterprise or Premium plans, The setup team has configured Fastly CDN for you, and manages it on your behalf with a built-in account. This means you do not have direct administration access using the Fastly web UI, where a ‘Purge’ button can be found.

However, you have been issued with an “API” key that allows you access to many actions on your account, and you can initiate a purge using this.

To purge a single page

Fastly lets you purge individual URLs with no authentication.

curl -X PURGE $url

That’s it!

To Purge all

You need use the API key.

All projects with Fastly configured should have had the env:FASTLY_API_TOKEN set in their

Some older dedicated plans do not have it here, and the API token is instead stored in a text file on the server. If you can’t find the value in the environment variables, check for a file called /mnt/shared/fastly_tokens.txt on your server.

This key can be used to construct a purge_all API request.

The Fastly API documentation says to construct a request like this:

POST /service/SU1Z0isxPaozGVKXdv0eY/purge_all HTTP/1.1
Accept: application/json

So, from a local CLI, run this sequence to retrieve your keys:
(or you can just set the variables to the values you can see in the web console yourself)

FASTLY_SERVICE_ID=$(platform --project=$PROJECTID --environment=master variable:get env:FASTLY_SERVICE_ID --pipe)
FASTLY_API_TOKEN=$(platform --project=$PROJECTID --environment=master variable:get env:FASTLY_API_TOKEN --pipe)
# Legacy: If these environment variables do not exist on your installation, try looking for a file called `/mnt/shared/fastly_tokens.txt` instead.

curl -H "Fastly-Key: $FASTLY_API_TOKEN" \
  -X POST "${FASTLY_API_URL}/service/${FASTLY_SERVICE_ID}/purge_all"


curl -H "Fastly-Key: nfDDFUahPwV4wQiJOMbLwJsCBy3Wh4TQ" -X POST ""


^ mind the quotes there.

Verify it really worked

To empirically test, you could retrieve a page from your site and see if it looks right :slight_smile: , or immediately make a network request and check the cache headers and dates:

curl -I -s $url

HTTP/2 200
cache-control: max-age=3600, public
last-modified: Fri, 06 Mar 2020 01:36:16 GMT
date: Fri, 06 Mar 2020 02:26:54 GMT
via: 1.1 varnish
age: 0
x-served-by: cache-syd10142-SYD, cache-hkg17927-HKG
x-cache: MISS, MISS

The x-served-by and via confirm that a cache is working.
Unless someone else has already requested this page just ahead of you, you should see a MISS in the x-cache.
Either way, the age (in seconds) should be low, and the date should be fresh. Ignore the last-modified

Verify via API (just FYI)

To verify the command ran as expected, you can retrieve a list of the recent events, with a command like:

curl -H "Fastly-Key: $FASTLY_API_TOKEN"  -X GET "${FASTLY_API_URL}/events?page[number]=1&page[size]=10"

…which should return a response including something like:

      "id": "miaXP6k1OLwUdOIXcKkiHG",
      "type": "event",
      "attributes": {
        "customer_id": "rSam6DCAgeyDU7gSoC5pJi",
        "description": "Purge all was performed",
        "event_type": "service.purge_all",
        "ip": ",",
        "metadata": {},
        "service_id": "ZknOBmPqIK5M71NgZMhLYT",
        "user_id": "TdqCvp120Tm185r3gn4DYR",
        "created_at": "2020-03-06T01:35:35Z",
        "admin": false


This is a quick method to flush your CDN cache as needed.

There are many other actions possible through the Fastly API though not all will be available to the account granted with that API key.

If you are using a CMS like Drupal, then a Fastly module can be installed to integrate cache management into your CMS. This provides an easier interface to actions like this. This approach also lets the CMS invoke a CDN purge when things change, so is recommended if you need to tune things finer.


Can use the API to check the fastly service performance also.
One important thing is the hit ratio. To see what it’s been like in the last 24 hours:

I’m on OSX, where the date function is non-standard, so I’ll use php to generate a timestamp for yesterday to define a request range.

For Grid, where the environment is master, do this. If your production environment is named differently, adjust accordingly.

FASTLY_SERVICE_ID=$(platform --project=$PROJECTID --environment=master variable:get env:FASTLY_SERVICE_ID --pipe)
FASTLY_API_TOKEN=$(platform --project=$PROJECTID --environment=master ssh "echo \$FASTLY_API_TOKEN")
yesterdayTS=$(php -r "echo(strtotime('yesterday'));")

curl -s -H "Fastly-Key: $FASTLY_API_TOKEN" \
    "${FASTLY_API_URL}/stats/service/${FASTLY_SERVICE_ID}?by=day&from=${yesterdayTS}" \
    | jq ".data[].hit_ratio"

example response:


75% is not great.

There are a hundred other sats in that response you can investigate also.


curl -s -H "Fastly-Key: $FASTLY_API_TOKEN" \
    "${FASTLY_API_URL}/stats/service/${FASTLY_SERVICE_ID}?by=day&from=${yesterdayTS}" \
    | jq -r '.data[] | "hits:\(.hits)" , "miss:\(.miss)" , "pass:\(.pass)" , "----",  "requests:\(.requests)"  '

for a slightly extended report.


This shows that the fastly report of 75% “Cache hit ratio” may be misleading as a guide to app performance, as the vast majority of the requests here were given a PASS, and Fastly chooses to not count PASS in the hit/miss summary.
In this case, the number of requests hitting the server vs the number of requests that Fastly intercepted is MUCH greater than it seems.

So your app may be suffering badly even when Fastly says it’s being efficient!