An infinite TTL alone does not prove a leak. Find the owning cache group and compare key growth through an actual regeneration cycle.
Quick answer
WP Rocket 3.23.3.1 documents a cache-group correction for orphaned keys associated with Above the Fold, Used CSS, Preload Fonts, and Lazy Render Content. If Redis memory keeps growing, confirm those keys belong to this site and compare their lifecycle before and after a supported update. A TTL of -1 means a key has no expiration; it does not, by itself, mean the key is defective or safe to delete.
Separate a cache leak from ordinary traffic growth
Start with the hosting dashboard: note used memory, key count, evictions, hit rate, request volume, and observation times. Compare a normal business window with a similar window, rather than comparing a quiet staging site to a busy store. More products, translations, query variants, or users can legitimately produce more cache objects. Memory allocated by Redis can also behave differently from the bytes occupied by live values.
Identify every application using the Redis instance and the namespace assigned to this WordPress site. Sessions, queues, locks, and another site may share the same server or database. Ask the host for the supported way to inspect one namespace. Never use a global flush as the first diagnostic step: losing unrelated state can create customer-facing failures while erasing the evidence you needed.
Inspect a bounded sample of owned keys
Use cursor-based SCAN in the host-approved session, starting with a confirmed prefix and a modest count. Continue only as needed to understand the affected group. SCAN is incremental and can return duplicates while the database changes, so deduplicate a captured inventory before reporting counts. The COUNT argument is a work hint, not a promise about the number of results returned.
For a small selection, record key name, type, remaining TTL, approximate size if the host supports that measurement, and the feature expected to own it. Keep raw values out of shared reports because cached objects may contain private information. If TTL returns -2, the key disappeared between discovery and inspection; that is a lifecycle observation, not proof that your command failed.
Illustrative diagnostic worksheet. Values are examples, not measurements from a customer site.
Follow one feature through its lifecycle
Choose a staging page whose generated CSS or font data you can recognize. Capture the owned keys, make one relevant change, and trigger the documented regeneration path. Observe which keys are replaced, invalidated, or left behind. Then repeat the cycle several times with the same fixture. Growth that tracks each regeneration without later retirement deserves closer investigation.
Do not invent cache-group names from this article. The object-cache implementation, plugin version, and site configuration determine the actual namespace. Compare the installed WP Rocket source or obtain the mapping from support. Dedicated groups improve isolation, but updating the plugin should not be assumed to reclaim every old key automatically. Record both the new-key behavior and the fate of pre-update objects.
Update without disrupting the rest of Redis
Test the supported plugin update on staging, preserve configuration, and use documented feature-specific cleanup when available. If the host proposes removing historical keys, ask for an exact namespace and group list plus a recovery plan. Run the cleanup in a controlled window, watch origin load, and verify that affected CSS, fonts, and page rendering regenerate correctly.
Afterward, monitor a complete regeneration and cache-expiry cycle. Record absolute memory, owned key counts, and rates of growth at comparable traffic. A short immediate drop can come from eviction or a flush and may not prove the underlying lifecycle is fixed. Conversely, memory remaining high immediately after the update does not establish that the fix failed. The useful result is stable ownership and repeatable retirement behavior.
What should the support ticket include?
Include the WP Rocket and object-cache plugin versions, Redis topology, site prefix, affected feature, timestamps, a redacted key sample, and before-and-after counts. State whether the instance is shared and whether evictions occurred. Report measured behavior without claiming a leak from TTL alone. This gives support enough context to distinguish old orphaned data, a current invalidation defect, and expected persistent caching.
Working example
Use this as a read-only starting point or an evidence worksheet. Replace example identifiers with the approved staging fixture.
# Use an authenticated host-approved Redis session.
SCAN 0 MATCH confirmed-site-prefix:* COUNT 100
TTL exact-key-returned-by-scan
TYPE exact-key-returned-by-scan
# TTL -1: no expiration; -2: key no longer exists.
Before closing the work
- Other site namespaces remain untouched.
- Owned stale keys have a documented lifecycle.
- Required CSS and fonts regenerate.
- Memory trends are compared at similar load.
For help applying these checks to a live site, HandL WP WordPress support can review the affected configuration and verify the result. Continue with WP Rocket preload and scheduled jobs when that adjacent issue matches your evidence.
Helpful references