Real⁠-⁠Time Purge

Real-Time Purge allows you to instantly delete the cache of your content at Azion. When you update content at your origin, you must choose the best strategy for updating it in Azion’s cache.

When configuring your cache policies, you determine the amount of time you want your objects to be cached at Azion. When you update your content at the origin, Azion can continue providing a cached copy for as much time as you have set it to be cached. With Real-Time Purge, you can instantly delete the cache of your content at Azion, from either Edge Caching or L2 Caching. This way, Azion system fetches the latest version of your content in the origin.

However, if specific cached objects must be removed at the edge before they expire, you have the option to purge cache with Real-Time Purge. Regular cache purging as part of your application helps you:

  • Ensure that users receive the most up-to-date content and experience the latest changes to your application.
  • Prevent users from seeing obsolete content.
  • Deliver content that is compatible with modern browsers and devices.
  • Provide dynamic content caching and API responses without sacrificing the user experience.
  • Control how your objects are served by Azion.
  • Manage obsolete or outdated objects, helping your developers to build reliable, resilient, and better performing solutions.

To ensure safe and controlled cache purges, you should maintain version markup in an object name. When you update the object at your origin, you can add the version in the object name, forcing each modification of your content to be treated as a new object by Azion.

To version your objects, you can use a sequential number, a timestamp, or other mechanism that you think is most appropriate as a version markup. For example, instead of naming an image as image.jpg, you could name it image_1.jpg and, when you need to update it, change the version to image_2.jpg.

This way, each content update will be treated as a new object by Azion, which allows you to control which object a request should return, even if the user has the previous version locally saved in the browser cache or in some intermediate cache.

You’ll also be able to provide different versions of your objects to different users and simplify the rollback process in case of issues with your update.

If you use the DEL method to remove the object from the cache instead of Real-Time Purge, the user’s first GET request will be made to the origin. However, this method prevents Azion from delivering stale objects if the origin is inaccessible, delivering an error page instead.

You can use the DEL if your goal is to:

  • Remove content from Azion’s cache after it has been removed from the origin.
  • Force the removal and later update of contents for which a timestamp is unreliable.
  • Force the delivery of an error page instead of a stale object if your origin is inaccessible and Azion is unable to get the latest version of your content.

Real-Time Purge offers you two layers to purge your cache from:

  • Edge Caching: purges cache kept with Azion at the edge.
  • L2 Caching: purges cache from the second layer at the edge. Can only be done when the L2 Caching module is active.

Purges cached objects by entering a list of URLs as an argument.

A URL purge is non-recursive, which means that only the URLs entered will be purged from the cache. The URLs are automatically converted to their respective cache keys, without considering any content variation in the same URL.

The expiration of content variations based on query string can be run using URL purge, since a query string is a component of the URL, as long as the arguments used for content variation are sent in the correct order in which they were presented. If you enabled Query String Sort, either sort the arguments in the request, or consider using cache key purge or wildcard purge as an alternative.

The URL format must respect the standard: scheme://host or just host, followed or not by a /path and the ?query-string. When the scheme isn’t informed, both HTTP and HTTPS contents will be purged.

For example:


Purges cached objects by passing a list of cache keys as an argument.

You can specify an advanced cache key to identify different variations of an object, based on:

To purge all variations, you must search for the cache keys individually.

Purges cached object by giving a wildcard expression as an argument.

The wildcard expression format must be according to the standard: scheme://host or just host, followed or not by a /path and the ?query-string, with an asterisk character (*) in the path or query string. You can even use multiple wildcards to match a complex pattern of a path.

For example:


Application Acceleration purge

Section titled Application Acceleration purge

You can purge objects with content variation based on cookies or query strings using the Advanced Cache Key feature from the Application Acceleration module.

To remove objects with cookie-based variation, you can use a purge by cache key, entering all variations individually, or a purge by wildcard, using @@* at the end.

To purge objects with variation based on query string, you can use:

  1. A cache key purge, entering all the variations individually.
  2. A wildcard purge, using ?* at the end.
  3. A URL purge, entering only the arguments used in the cache key in the URL.

If you use Query String Sort, the arguments must be sent in alphabetical order.

You can purge images that are treated by Image Processor.

In addition to host and path the cache key must include the separator ?, key-value pairs related to the type of processing, and the @@ separator for identifying image format variation supported by the browser. For example:


You can use a cache key purge, entering all variations individually, or a wildcard purge, using * at the end.

If you use the Slice feature in your application, large files might still remain in cache. To perform a purge in this case, you must list the cache keys for each slice individually.

To purge all file slices using this optimization, you can use a wildcard purge:


By default, Azion allows caching of GET and HEAD methods only. You can enable POST or OPTIONS caching with the Application Acceleration module.

To purge these objects, you can either use a cache key purge, entering all variations individually or a wildcard purge, using @@* at the end.

The purge is an operation that is completed almost instantly, so no confirmation of the operation is submitted. You can expect your purges to be completed in less than 3 seconds, except in the case of consistent use of rate limits.

When needed, you can query the purge history to filter the user who made the purge, the time, argument list, purge type, and method.

The purge operation is performed according to the following usage limits, based on the type and number of objects that are being purged:

  • URL and cache key purges: up to 10,000 objects every 60 seconds, up to 200 requests with 50 objects per request, per client. The URL and cache key are limited to 4,096 characters.
  • Wildcard purges: up to 2,000 requests per day (per 24h interval), one wildcard URL per request. The wildcard URL is limited to 256 characters.
  • Purge history is limited to 6 months and up to 1 million requests.