What matters first: WordPress may load wp-content/object-cache.php before normal plugins. If that drop-in requires Redis and cannot connect, front end, admin, cron and CLI can all fail or become very slow.
What this symptom actually tells you
Restarting Redis may restore service temporarily, but host, port, password, database selection, network and eviction policy still need verification.
Capture evidence before changing anything
- Capture the Redis error, destination host, port and database index.
- Check whether object-cache.php remains active even when its plugin is disabled.
- Test connectivity from the WordPress runtime, not only the host.
- Inspect Redis memory, evictions, authentication and restart history.
Most common causes
- Service unavailable: Redis is stopped, restarting or unreachable across the container/network boundary.
- Credential mismatch: The drop-in uses an old password or database index.
- Persistent stale drop-in: The plugin was removed but object-cache.php still loads.
- Memory pressure: Evictions or OOM restarts make cache behaviour unstable.
Safe diagnostic and repair sequence
- Restore Redis connectivity or temporarily remove the specific drop-in with a rollback ready.
- Align connection settings across environment, plugin and container secrets.
- Flush only the affected cache database after confirming it stores no sessions or queues.
- Re-enable persistent caching and test cold and warm requests, admin and cron.
How to choose between the likely causes
Do not treat Service unavailable and Credential mismatch as interchangeable. Redis is stopped, restarting or unreachable across the container/network boundary. By contrast, the drop-in uses an old password or database index. Use two checks to separate them: Capture the Redis error, destination host, port and database index; and check whether object-cache.php remains active even when its plugin is disabled. Those observations usually show whether the next safe move is to restore Redis connectivity or temporarily remove the specific drop-in with a rollback ready or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not flush an entire shared Redis instance blindly. Other sites, sessions, queues or locks may use different logical databases or prefixes.
How to verify the repair
- Front end, admin, REST and cron work with the intended cache state.
- Redis remains connected through restart and realistic load.
- No stale data, cross-site keys or eviction storm appears.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
Restarting Redis may restore service temporarily, but host, port, password, database selection, network and eviction policy still need verification.
- Capture the Redis error, destination host, port and database index.
- Check whether object-cache.php remains active even when its plugin is disabled.
- Test connectivity from the WordPress runtime, not only the host.
- Inspect Redis memory, evictions, authentication and restart history.
What must be verified
- Front end, admin, REST and cron work with the intended cache state.
- Redis remains connected through restart and realistic load.
- No stale data, cross-site keys or eviction storm appears.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Will simply restarting Redis fix this permanently?+
A restart often restores service temporarily, but it does not confirm that host, port, password, database index, network path, and eviction policy are all correctly aligned. Without checking those, the same connection failure can recur under load or after the next deploy.
Is it safe to flush the entire Redis instance to clear the error?+
Not on shared Redis. Other sites, sessions, queues, or locks may live in different logical databases or use different key prefixes on the same instance, so a blind flush can break unrelated systems. Only flush the specific cache database confirmed to hold no sessions or queues.
Why does object-cache.php keep loading even after I deactivate or delete the caching plugin?+
object-cache.php is a drop-in file that WordPress loads directly from wp-content before normal plugins run, so removing the plugin does not remove the drop-in itself. The stale file has to be removed or replaced directly, otherwise WordPress keeps trying to connect to Redis through it.
Could this be a memory problem rather than a pure connectivity issue?+
Yes. Memory pressure causing evictions or out-of-memory restarts on the Redis side can produce the same connection instability as a genuine network or credential fault. Checking Redis memory usage, eviction counts, and restart history alongside the connection settings is necessary to tell the two apart.