Why Your Redis Cache is Missing

Redis is a storage service; WordPress needs a compatible object-cache integration to use it across requests. Installing a Redis server or setting WP_CACHE in wp-config.php is not enough. WordPress distinguishes the object-cache.php drop-in from the advanced-cache.php page-cache drop-in in its configuration handbook. That distinction should be the first check, not an afterthought.

Start with the symptom you actually have

The last row is the trap. A Cloudflare or server-cache MISS is about a rendered page. It says nothing conclusive about object entries used while PHP built that page. You can have a page-cache miss and a healthy Redis object cache at the same time. Conversely, a page-cache hit may never execute WordPress PHP, so it is a poor test of Redis.

If WordPress cannot see a persistent object cache

1. Identify the integration. Check the active host or plugin documentation. Some hosts manage object caching without the popular Redis Object Cache plugin. Do not install a second drop-in over one the host owns.
2. Check the drop-in. WordPress loads wp-content/object-cache.php when available. If it is absent, inactive, or belongs to a different cache product, the Redis server alone will not make WordPress use it. The WordPress cache loader reference documents this path.
3. Read connection diagnostics. For the Redis Object Cache plugin by Till Krüss, its settings page and wp redis status report the integration state. Check host, port or socket, authentication, database, and whether the plugin reports a valid drop-in. The plugin’s configuration and command reference lists those settings. Other integrations have different commands.
4. Check deliberate disabling. That plugin supports WP_REDIS_DISABLED as an emergency bypass. If it is set, find out why before reversing it. A connection outage, a host migration, or a competing drop-in may be the real issue.

If you have WP-CLI access, wp cache type can offer another clue. Its documentation warns that it guesses from object-cache classes, so do not use its label as sole proof of a working Redis connection. Run commands against the same WordPress installation and site context you are diagnosing.

If Redis connects but the cache keeps missing

A miss can be normal: the first request for a key has no stored value, an entry expired, or the application chose a different key. A low hit rate becomes a problem when comparable requests should reuse expensive data and repeatedly rebuild it. Compare the same page and visitor state over several requests, with the page cache bypassed only for the diagnostic test. Do not compare a logged-in admin request with an anonymous visitor request and call the difference a Redis failure.

Where the integration exposes metrics, check whether object-cache gets and hits change as expected. If a dedicated Redis instance or host dashboard exposes Redis statistics, inspect keyspace misses and evictions over an interval. Redis’s eviction guide explains how memory limits can remove keys. Server-wide hit numbers may include other applications, so they are not a clean WordPress benchmark on a shared instance.

Also check whether a plugin flushes the object cache on every request, uses very short time-to-live values, or generates changing keys. Those are hypotheses to investigate in logs and code, not diagnoses to assert from one low percentage. If a host recently moved Redis, verify the connection target and any site-specific key prefix before changing memory limits.

A short WP-CLI check

With the site owner’s permission to run a temporary cache probe, these commands use a unique key and a 60-second lifetime. Run each line as a separate process from the correct WordPress directory. The second line tests whether the value survived the first process; the third removes it. A successful single-process set/get would prove much less.

wp cache set wpcolt_probe ok wpcolt_probe 60
wp cache get wpcolt_probe wpcolt_probe
wp cache delete wpcolt_probe wpcolt_probe

If the second command returns ok, that is evidence of persistence for this CLI site context, not a benchmark for all cache groups or for web traffic. If it misses, compare the CLI and web configurations, check the drop-in and connection diagnostics, and confirm the group was not excluded from persistence. The WP-CLI cache reference documents these commands.

My verdict: do not fix a “Redis miss” by adding another cache plugin or flushing everything. Name the failing layer, collect its own evidence, then change one cause. For most site owners, a valid drop-in and a confirmed connection are a more useful starting point than a page-header screenshot or a generic cache score.

Frequently asked questions