Feed Cache and Manual Cache Clearing

Benecaster caches the compiled RSS feed for each tier on each show. When a subscriber’s podcast app polls their feed URL, Benecaster serves the cached version rather than rebuilding the RSS from scratch on every request. This keeps feed delivery fast regardless of how many subscribers you have.

In most cases the cache is invisible — it refreshes automatically when you publish or update an episode. Occasionally you’ll need to clear it manually.

---

When the Cache Refreshes Automatically

The feed cache is invalidated automatically when:

• You publish a new episode
• You update an episode’s title, audio URL, or availability dates
• A subscriber’s token changes (their feed is regenerated on the next poll)
• Tier mapping changes affect episode availability

In these cases you don’t need to do anything. The next time a subscriber’s podcast app polls, it gets a freshly compiled feed.

---

When You Need to Clear Manually

Manual clearing is occasionally needed when:

• You edited availability settings and the feed isn’t reflecting the change. Availability date changes trigger automatic invalidation for most cases, but if you’re testing and something looks wrong, a manual clear will rule out a stale cache.
• You changed a setting that affects feed output — like the feed slug, show artwork URL, or iTunes category — and want to confirm the new value is live.
• You reordered episodes manually and the feed is still returning the old order.
• Troubleshooting a subscriber complaint. If a subscriber reports stale content, clearing the cache for their show is the quickest first step.

---

Clearing the Cache

Go to Benecaster → Settings → General → Advanced.

Two buttons are available:

Clicking either button opens an inline confirmation prompt. Confirm to proceed. The result — success or error — is shown inline without a page reload.

Cache clearing is instant and has no effect on subscriber tokens, episode data, or any other stored records. It simply marks the existing cached feed as stale; Benecaster rebuilds it from your current episode and settings data on the next feed request.

---

Staging Sites

On a staging site, a Clear feed cache button is always visible at the top of every Benecaster admin screen — not just in Settings — and fires immediately without a confirmation dialog. Staging mode prioritizes the fast iteration workflow over the extra step. See Setting Up a Staging Site for Benecaster.

---

Cache Warmup

Benecaster pre-warms feed caches every hour via a background job. This means feeds are compiled and ready in advance — when a subscriber’s podcast app polls, it almost always hits a pre-built cache rather than triggering a live compilation. The warmup runs across all active shows automatically; no configuration is needed.

---

Cache Duration

The default cache TTL (time-to-live) is 1 hour. This means that even without a manual clear, cached feeds are at most 1 hour out of date for background changes (show artwork, iTunes category, etc.). The TTL is set to match the hourly warmup cycle — the warmup pre-builds the cache at the same cadence it expires, keeping feeds consistently warm. The TTL is configurable in Settings → Feeds → Cache invalidation interval if your workflow needs a different window (options: 5 minutes, 15 minutes, 1 hour, 6 hours).

On staging sites the TTL is 45 seconds by default so content changes appear almost immediately during testing.

Plugin updates: the feed cache is flushed automatically whenever the plugin updates. Feed XML structure can change between versions, so Benecaster clears all cached feeds at update time to ensure subscribers receive correctly formatted output on their next poll.

Note that the TTL only governs background changes. Episode publishes, title or audio URL edits, and availability date changes all invalidate the affected feeds immediately — subscribers see those changes on their next poll regardless of the TTL setting.