Slow Feeds or Feed Loading Errors

Slow or failing feed requests are almost always a server capacity issue, not a Benecaster configuration problem. The four most common causes are below — work through them in order.

1. No object cache at a large subscriber count

At 500+ subscribers, feed poll volume can strain a shared or entry-level VPS database. Every feed request that misses the cache runs a set of database queries to compile the subscriber’s episode list. Without Redis or Memcached absorbing repeated requests, those queries stack up under load.

Fix: Install and configure an object cache. Redis is the most common choice; most managed WordPress hosts offer it as an add-on. See System Requirements for minimum specs.

Once an object cache is in place, Benecaster serves cached feed responses in memory — database load drops dramatically and feed response times improve from seconds to milliseconds for cache-warm requests.

2. Stale cache serving unexpected content

If subscribers are seeing episodes they shouldn’t, or not seeing new episodes that have been published, the feed cache may not be invalidating correctly.

Quick test: Go to Benecaster → Settings → Advanced → Clear Feed Cache and ask the affected subscriber to refresh their app. If the issue resolves immediately after clearing, the cache wasn’t being invalidated on the expected trigger.

Common causes of missed invalidation:

A caching plugin is storing feed responses as full-page HTML and not respecting Cache-Control: no-store (see item 4 below)
Object cache TTL is set longer than expected by a third-party plugin
An episode availability change (tier or date) didn’t trigger a cache bust — contact support with the episode ID and the exact change made

See Feed Cache and Manual Cache Clearing for more detail on what triggers automatic invalidation.

3. PHP memory limit too low

Feed compilation for large episode archives requires adequate PHP memory. Generating a feed for a show with 200+ episodes and multiple tier rules is more memory-intensive than a typical WordPress page request.

Minimum: 128MB
Recommended: 256MB for shows with 100+ episodes

Check your current limit in Benecaster → Support Mode → Diagnostic Snapshot → Environment — it shows memory_limit alongside other PHP configuration values. If the limit is below 128MB, increase it in php.ini, wp-config.php (ini_set('memory_limit', '256M')), or your host’s control panel.

4. A caching plugin intercepting feed requests

Some full-page caching plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache) can cache authenticated URLs including private feed URLs, serving a cached response to a different subscriber — or storing a compile-time snapshot that ignores live tier changes.

Benecaster sets Cache-Control: no-store on all feed responses, but some plugins override this header or bypass it entirely.

Fix: Add your feed URL pattern to the caching plugin’s exclusion list. The pattern to exclude depends on your permalink structure — typically /?token=* or /podcast-feed/* or /feed/podcast/*. See Caching Plugin Configuration for plugin-specific instructions.

Feed requests timing out entirely

If subscribers are seeing timeout errors rather than slow responses:

Enable WordPress debug logging: add define('WP_DEBUG_LOG', true) to wp-config.php
Ask the subscriber to reload their feed
Check wp-content/debug.log immediately after — look for PHP fatal errors, slow query warnings (query time over 1s), or memory exhaustion notices

The debug log entry will usually point directly at the cause. Share it with support if the source isn’t immediately clear.

Still slow after all four checks?

If feed response times remain high after adding an object cache and excluding feeds from full-page caching, the next step is profiling. Enable Benecaster → Support Mode and use the diagnostic snapshot to capture server environment details, then contact support — include the snapshot reference and a description of the subscriber count and average feed response time you’re seeing.