Skip to main content
Purge by Pattern invalidates a precise set of cached objects without dumping the whole cache. This is the right tool for deploys, content fixes, and incident response.

When to use this

  • After a deploy that changes specific paths (/static/main.js, /api/v1/*).
  • After fixing a content bug that’s already cached.
  • When TTL is too long for the asset you just updated.
For wholesale invalidation, use Purge All — but pattern purges are almost always preferable.

How patterns work

The first request after a purge is a MISS. Plan your purge timing so the resulting origin spike is acceptable.

Pattern rules

  • Must start with /.
  • * is a wildcard matching one or more characters.
  • Up to 10 patterns per purge request.
* matches eagerly. /api/* purges every API response on the distribution. Scope tightly when you can.

Console flow

Purge by Pattern

Purge by Pattern

  1. Enter one pattern per line in the input box.
  2. Click Purge to dispatch.
Execute Purge

Execute Purge

Purge propagates globally within a few seconds.

Purge via API

Response:
Poll the purge job:
See the CDN API reference for canonical fields.

CI/CD integration

GitHub Actions

Shell helper

Verify the purge

Operational tips

  • Purge before flipping traffic. For blue/green deploys, purge the green hostname after the new build is live, not before.
  • Use exact paths over wildcards. /static/main.abc123.js invalidates one object; /static/* invalidates everything and risks an origin spike.
  • Avoid frequent global purges. Each purge is a coordinated edge-wide operation. Hashed asset URLs make most purges unnecessary.
  • Monitor origin after a wide purge. Watch Cache hit ratio — it dips immediately, then recovers as the cache rewarms.

Limits and quotas

  • Up to 10 patterns per request.
  • Purges are async; completed status typically lands within seconds, sometimes up to a minute under heavy load.
  • Bulk purges (>1000/day) should batch and back off on 429.

Troubleshooting