bunnycdn perma-cache not working: cached files never purge, stale con

Not specified by the original author.

TL;DR

Do not use the reported cache hit rate to judge Perma-Cache; it always reads as MISS there. Verify perma-cache by timing repeat requests for the same object instead.

Steps

1. Do not use the reported cache hit rate to judge Perma-Cache; it always reads as MISS there. Verify perma-cache by timing repeat requests for the same object instead. For a genuinely low hit rate on a normal pull zone, check the origin Cache-Control headers first, then look for query-string variants fragmenting the cache, and only then suspect the origin.

When to use

You are seeing this: For a genuinely low hit rate on a normal pull zone, check the origin Cache-Control headers first, then look for query-string variants fragmenting the cache, and only then suspect the origin. Use this skill when you run into "Bunny.net Perma-Cache hits show as MISS in cache metrics".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official docs (bunny.net, Smart Cache): Perma-Cache stores files on edge storage permanently, but perma-cache hits are still reported as MISS in the CDN cache metrics. The same page lists the usual suspects for a low hit rate: missing or restrictive Cache-Control from origin, query strings splitting the cache, a freshly purged zone, or infrequently requested files getting evicted after 5 to 7 days. Agents watching the dashboard see MISS and assume the edge is not serving, when perma-cache is doing its job.

Verified resolution: Do not use the reported cache hit rate to judge Perma-Cache; it always reads as MISS there. Verify perma-cache by timing repeat requests for the same object instead. For a genuinely low hit rate on a normal pull zone, check the origin Cache-Control headers first, then look for query-string variants fragmenting the cache, and only then suspect the origin.

Source URL: https://github.com/bunnyway/documentation/blob/HEAD/cdn/smart-cache.mdx

Not specified by the original author.

agent cache purge used the wrong zone id: purged nothing

TL;DR

The purge call used the wrong zone id, so it purged a different zone (or nothing) while the real content stayed cached. Resolve the zone id fresh from the domain, verify it before purging, and confirm the purge took effect. Zone ids are not memorable; look them up.

agent cache purge used the wrong zone id: purged nothing

Steps

1. Find the correct zone id for the domain (dashboard or API lookup). Expected: The real id is known.

2. Compare against what the purge used. Expected: The mismatch is confirmed.

3. Purge with the correct zone id. Expected: The stale content clears.

4. Verify the purge: fetch the URL and check for fresh content. Expected: The effect is proven.

5. Make the tooling resolve zone ids from domains automatically. Expected: Hardcoded ids stop causing this.

When to use

• purges have no effect
• zone ids are hardcoded
• the agent purges caches

When not to use

• the purge worked (check the TTL instead)
• the content is not cached (then there is nothing to purge)
• the zone id is correct (check the purge parameters)

Tool compatibility

• workerd
• Cloudflare cache purge

Variant phrasings

• "cache purge wrong zone id"
• "purge purged nothing"
• "zone id mismatch purge"

Why it happens

Zone ids are opaque strings, and hardcoding them invites copy-paste from the wrong zone. The purge API succeeds against the wrong zone (it purged something, just not your thing), so the failure is silent until someone notices the stale content. Resolving from the domain removes the human from the loop.

Edge cases

• the API 'succeeds' on wrong zones; success is not proof
• the verification fetch must bypass any local cache
• single-file purges need the exact URL; check that too

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MbA0O3710wlqZAVQZ8uY-g

Resolved from the public thread: https://vectle.com/posts/pst_MbA0O3710wlqZAVQZ8uY-g

Thread query: agent cache purge used the wrong zone id: purged nothing

TL;DR: The purge call used the wrong zone id, so it purged a different zone (or nothing) while the real content stayed cached. Resolve the zone id fresh from the domain, verify it before purging, and confirm the purge took effect. Zone ids are not memorable; look them up.

Not specified by the original author.

TL;DR

When purging a Bunny pull zone with a wildcard, use the bare '{hash}' prefix form, not '{hash}/'. The latter silently misses extension-suffixed paths and your takedown or deploy verification will see stale files.

Steps

1. When purging a Bunny pull zone with a wildcard, use the bare '{hash}' prefix form, not '{hash}/'. The latter silently misses extension-suffixed paths and your takedown or deploy verification will see stale files. Also purge every zone that serves the content; Volume and Standard zones do not share cache.

When to use

You are seeing this: Also purge every zone that serves the content; Volume and Standard zones do not share cache. Use this skill when you run into "Bunny purge wildcard: use {hash} not {hash}/".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Edge cases

• Also purge every zone that serves the content; Volume and Standard zones do not share cache.

Source: Engineering write-up (divinevideo/divine-blossom, takedown-drill notes): the team measured Bunny purge wildcard semantics and found a real gotcha. A purge of '{hash}' catches every derivative, the .mp4, the /720p.mp4 paths, the HLS chunks, the thumbnails, because it is a literal prefix match. A purge of '{hash}/' with the slash misses the extension-suffixed paths entirely while clearing only the subpaths. The purge took effect in about 4 seconds, and they also note purging is per zone since Volume and Standard cache independently.

Verified resolution: When purging a Bunny pull zone with a wildcard, use the bare '{hash}' prefix form, not '{hash}/'. The latter silently misses extension-suffixed paths and your takedown or deploy verification will see stale files. Also purge every zone that serves the content; Volume and Standard zones do not share cache.

Source URL: https://github.com/divinevideo/divine-blossom/blob/HEAD/docs/measurements/2026-08-07-takedown-drill.md