---
title: Getting started with purging
summary: null
url: >-
  https://www.fastly.com/documentation/guides/full-site-delivery/purging/getting-started-with-purging
---

Purging is the act of explicitly removing content from a cache, rather than allowing it to [expire](https://www.fastly.com/documentation/reference/glossary/#term-expiration) or be [evicted](https://www.fastly.com/documentation/reference/glossary/#term-eviction). You may want to purge content because it's incorrect, out of date, or because you have a breaking update. Once content has been purged, subsequent lookups for that content will be served from the source rather than the cache.

## Purging and the content lifecycle

While an object is stored in cache, it has a freshness lifetime, also known as _time to live (TTL)_, and can be served without needing to be revalidated by the origin server. When an object is in cache and available to be used, it is considered _fresh_. Purging causes an object to become _invalidated_, which means although it may still exist on disk, it won't be used to satisfy requests. Instead, subsequent requests for the content trigger a request to an origin server for fresh content. 

Content that is invalidated, either because it has reached the end of its allotted lifetime (TTL) or because it has been invalidated by a purge, becomes [_stale_](https://www.fastly.com/documentation/guides/full-site-delivery/performance/serving-stale-content/). Depending on your configuration, stale objects can also be served to client requests even when your origin servers are down.

## Purging use cases

You may want to execute purging in different ways depending on your use case:

- **Manually purging**: At any time, you can run a manual purge to remove outdated or incorrect content or to clear old versions of data in the case of a manual deployment. Typically this is done [via the web interface](https://www.fastly.com/documentation/guides/full-site-delivery/purging/purging-a-url) or `fastly purge` CLI command.
- **Purging on deploy**: You can incorporate purging into your application's deployment process so that when you release a new version of your site, the cache is purged automatically.
- **Purging on content update**: You can configure content to purge whenever changes are made in your content management system. This approach is particularly useful when combined with setting a very long TTL in a `Cache-Control` header so that traffic to origin is minimized, but end users are still assured of up-to-date content.

## Methods and types of purges

Fastly has different purging methods that let you precisely purge only the objects you want updated. Each of our different purging methods can be initiated via the Fastly web interface, API, and CLI and are executed on a single service (not across multiple services):

- [**URL purge:**](https://www.fastly.com/documentation/guides/full-site-delivery/purging/purging-a-url/) Purges a single URL from cache.
- [**Surrogate key purge:**](https://www.fastly.com/documentation/guides/full-site-delivery/purging/purging-with-surrogate-keys/) Selectively purges content based on a shared identifier.
- [**Purge all:**](https://www.fastly.com/documentation/guides/full-site-delivery/purging/purging-all-content/) Purges all content under a service.

If you purge by URL or surrogate key, Fastly gives you the option to execute the purge as a soft purge or a hard purge. A _soft purge_ invalidates an object and marks it as stale. The next time a user requests the object, they'll be served the stale object and then the updated object will be retrieved from origin. Stale objects can also be served to client requests even when your origin servers are down. 

A _hard purge_ permanently invalidates cached objects and makes them unusable for future requests. It forces Fastly to retrieve that object again from your origin servers before it can be re-cached in Fastly POPs. Purge all is a hard purge.

## Limitations and constraints

- Purge-all operations contribute to global [API rate limits](https://www.fastly.com/documentation/reference/api/#rate-limiting).
- Surrogate key and URL purges are not counted as part of API rate limits but are separately limited to an average of 100,000 purges per hour, per customer. In the case of surrogate key purges, each key targeted counts as one purge regardless of how many objects are tagged with that key.

## What's next

Now that you understand how purging works, explore the purging methods available with Fastly in more detail in our guides on [purging a URL](https://www.fastly.com/documentation/guides/full-site-delivery/purging/purging-a-url), [purging with surrogate keys](https://www.fastly.com/documentation/guides/full-site-delivery/purging/purging-with-surrogate-keys), and [purging all content](https://www.fastly.com/documentation/guides/full-site-delivery/purging/purging-all-content).