Read purge logs

Each row shows time, scope, group, actor, status, and purged or rejected counts

Each log row is a complete record of one purge request, including partial failures.

Purge logs table rows showing group label and scope, requested URLs with records purged or rejected inputs, actor including a Service API purge, and status badges — Every row records scope, targets, actor, status, and time.

1. Request#

The Request cell shows the purge group as a label — Full Site, Specific URLs, Specific Image URLs, Cache Tags, or Rule: {ruleName} — with the scope beneath it as hostname · groupId, so a row is unambiguous when several domains share a log.

2. URLs#

The URLs cell lists the requested paths when the group had explicit targets, and falls back to Workspace cache or Domain cache for broad purges. The sub-line tells you the effect: either {n} records purged or {n} rejected: {inputs}, which lists exactly which inputs were refused.

3. Actor#

The Actor column shows the full name or email of the user who requested the purge. Purges created through the delivery API show Service API instead, which is how you tell an automated pipeline from a person.

4. Status and time#

Status renders the API's own values as uppercase badges: COMPLETED for a run that finished, REJECTED when any input was refused. There is no partial badge — a partially successful request is REJECTED with the offending inputs listed in the URLs cell, so a failed purge stays visible as evidence.

5. Requested#

Requested is the timestamp the purge was submitted, in the workspace timezone. Compare it with cache metrics to confirm a purge lines up with a hit-ratio drop — see Confirming a purge.

Expected result#

You can reconstruct any purge: what it covered, who asked, whether every target was invalidated, and when.

Reading a rejection#

A REJECTED row still tells you how much succeeded: the URLs sub-line reports the number of records actually purged alongside the inputs that were refused. Common refusals are malformed URLs, targets outside the domain, and entries that were not cached in the first place — no match is not an error, it is simply nothing to do.

Correlating with other data#

Because each row carries an actor and a timestamp, purge history lines up with cache hit-ratio movements, deploy times, and integration runs. That combination is usually enough to answer "why did this page change at 14:05?" without involving anyone who remembers the deploy.

Back to Read purge logs