Feed Request Log Retention

Benecaster logs every feed poll request to a local database table. The log is a powerful re-engagement and analytics tool, but it grows continuously and needs a retention strategy. This page covers what the log records, how fast it grows, and the knobs available to control its size.

---

What the Log Records

Benecaster maintains two tables:

benecaster_feed_request_log — the raw log. One row per feed poll request, recording:

• Show ID
• Token ID and prefix (null when the token is not found)
• Token status (valid, revoked, not_found, over_limit)
• Hashed IP address (not the raw IP)
• User agent string
• Country and region codes (from GeoIP lookup; null when GeoIP is unavailable)

Rows are approximately 250 bytes each (with indexes).

benecaster_feed_request_daily — the aggregate. One row per (show, date, token_status) combination, recording request counts and unique token / country counts. The nightly rollup cron aggregates yesterday’s raw rows into this table. Aggregate rows carry counts only — no token IDs, no IP hashes, no PII.

---

How Fast the Log Grows

These figures assume a typical poll interval (every 2–4 hours) and that every subscriber’s app is active. Actual numbers vary by app mix and churn level — revoked polls from cancelled subscribers add volume that raw-subscriber counts don’t predict.

Aggregate rows per year is modest regardless of show size — approximately 2,900 rows per year per show (365 dates × 4 token statuses × 2 shows), growing linearly with show count.

---

Sizing Your Host

A 500-subscriber show will write roughly 6 MB/day to the raw log at the default 30-day retention window — that is roughly 180 MB steady-state once the purge cycle reaches equilibrium. The aggregate table adds approximately 150 KB/year regardless of show size.

On hosts with a 1 GB database quota (SiteGround’s starter plan, for example), a large active show can consume 15–20% of the quota in feed-log rows alone. See Reducing Disk Usage → for host-specific guidance.

---

The Three Retention Knobs

1. Raw retention window

Location: Settings → GDPR / Privacy → Feed request log → Retention (days)

Default: 30 days. Range: 1–3650.

Controls how many days of raw feed-poll rows to keep. The nightly purge cron (runs at 02:30) deletes rows older than this window. Shortening the window is the fastest way to reduce log storage.

2. Aggregate retention window

Location: Settings → GDPR / Privacy → Feed request log → Aggregate retention (days)

Default: 365 days. Range: 1–3650.

Controls how long rolled-up daily count rows are kept. Because aggregate rows carry no PII, you can keep them for several years without meaningful privacy risk. The Analytics Dashboard add-on reads from this table — if you shorten it significantly you lose historical chart data.

3. Hard row cap

Location: Settings → Tools → Feed request log → Hard row cap

Default: 5,000,000. Minimum: 1,000.

A safety net for sites where raw volume spikes unexpectedly (for example, a viral episode or a misconfigured podcast app that polls every minute). When the nightly purge cron finds the raw log above the hard cap, it deletes the oldest rows down to 80% of the cap before running the normal retention purge. A warning notice is published to the admin notification panel — see Admin Notifications →.

The hard cap is not a substitute for setting an appropriate retention window. It fires only on the nightly cron pass — not in real time.

---

Emergency Guardrail Behavior

When the nightly cron detects the raw log has crossed the hard row cap:

1. Oldest rows are deleted until the count is at 80% of cap
2. A Warning notice is published to the admin notification panel — “Feed request log row count exceeded the configured hard cap and oldest rows were deleted”
3. The notice re-surfaces every 7 days while the log remains near the cap (you cannot permanently dismiss it while the condition persists)
4. The normal retention-window purge then runs on the trimmed table

The benecaster_feed_request_log_hard_cap_enforced action fires after each guardrail deletion — use it to route the event to external monitoring or alerting.

---

Log Level

Location: Settings → GDPR / Privacy → Feed request log → Log level

Options: All requests (default) or Failed requests only.

• All requests — every feed poll is written to the raw log regardless of token status. Powers full Analytics Dashboard feed request charts including poll-volume trends for active subscribers.
• Failed requests only — only revoked, not_found, and over_limit requests are written. Successful polls are skipped. This preserves the churn and re-engagement signal (cancelled subscribers still polling) while drastically reducing write volume on active shows.

On a show where most subscribers are active, the majority of polls are valid requests. Switching to “Failed requests only” can reduce raw log volume by 80–90%.

The aggregate rollup is unaffected — the nightly rollup simply sums whatever the raw log contains, so daily counts in the aggregate table accurately reflect whichever request classes you’re recording. If you don’t need full poll-volume charts in the Analytics Dashboard, “Failed requests only” gives you the re-engagement signal at a fraction of the storage cost.

See Settings Reference → for the toggle location.

---

Disabling the Log

Location: Settings → GDPR / Privacy → Feed request log → Log feed requests (toggle)

When disabled, no new rows are written to the raw log and the nightly purge and rollup crons skip entirely. Existing rows remain until you purge them manually from Settings → Tools → Feed request log → Purge now.

Disable the log when:

• Your host has a very tight database quota and you cannot afford the storage
• You have no plans to use the Analytics Dashboard add-on and the raw data is not valuable to your workflow
• You are running a small test or staging site where feed-log data is noise

---

Maintenance Controls

Settings → Tools → Feed request log provides:

---

GDPR Notes

Raw log rows include a hashed IP address (not the raw IP). They are linked to token_id — which ties to a subscriber’s WordPress user account. For this reason, raw rows for a specific subscriber are deleted when you run a right-to-erasure request from Settings → GDPR / Privacy → Delete a Subscriber’s Data.

Aggregate rows (benecaster_feed_request_daily) carry no PII and are not touched by right-to-erasure requests.