Your Redis object cache can say "Connected" and still be taking your site down. This release makes Site Doctor prove it either way.
Redis diagnostics that actually diagnose
Almost every Redis health check in the WordPress ecosystem - Site Health, the object-cache plugins' own status screens, most hosting dashboards - answers one question: did the connection succeed? They open a socket, send a PING, get a PONG, and report green.
That test cannot fail in the ways Redis actually fails. A Redis server can answer instantly while it is:
- rejecting every write it receives, because it hit its memory ceiling under a
noeviction policy;
- throwing keys away as fast as WordPress writes them, because the working set does not fit;
- serving another website's cached data, because two installs share one keyspace with no prefix;
- caching nothing that matters, because the
options group is on the ignore list;
- costing more time than it saves, because the round-trips outweigh the database work avoided.
In every one of those cases the drop-in still reports "Connected", and the site is slower - sometimes catastrophically slower - than it would be with no object cache at all.
While building this we reproduced the worst case on a real server: an 8MB Redis filled to its ceiling under noeviction. The drop-in did not degrade quietly. It threw during bootstrap and WordPress died - HTTP 500, the whole site - while every "Connected" indicator stayed green throughout.
Site Doctor now runs 21 Redis checks that talk to the server and read its running configuration: memory ceiling and headroom, eviction policy and eviction rate, hit rate, key isolation, cache group configuration, replication topology, disk persistence, connection reuse, memory fragmentation and round-trip latency. Each one carries its own severity and its own fix.
Safe by construction
The checks are read-only and run only when you ask - from the scan button or WP-CLI, never on a normal page load. They use INFO, CONFIG GET, DBSIZE and a single bounded SCAN. They never use KEYS, which would block your server for the length of your entire keyspace. A diagnostic that causes an outage is not a diagnostic.
Where your host blocks CONFIG GET - Kinsta, WP Engine and Cloudways among them - the affected checks say "cannot verify this here" and tell you how to find out yourself. They never report "ok" for something they could not measure. No data is not the same as no problem.
Also in this release
- New:
wp multitool redis runs the same diagnosis from the command line, bringing the CLI to 15 subcommands.
- Improvement: Site Doctor no longer reports the same autoload problem twice, no longer calls a 3-byte saving an optimization, and no longer lists slow queries that have no fix to apply.
- Fix: Site Doctor's findings no longer link back to the page you are already on.
- Fix: The Autoloader Optimizer's "optimize now" nag no longer appears on the Site Doctor page, which already tells you the same thing.
- Fix: External Call Optimizer no longer optimizes calls your site makes to itself. If something polls your own REST API often enough to look "chatty" - WPML's health checks do exactly this - the optimizer treated your own site as a third-party phone-home and cut its timeout to 5 seconds, which fails under load and surfaces as a false "REST API must be enabled for WPML" warning. A loopback to your own site was never a phone-home and is now never touched. Thank you to the site owner who reported it.
- Fix: The download no longer contains development files that were never meant to ship - local editor settings and a test cache. They were inert and contained no credentials, but they had no business being in the zip.
Full technical reference for every check, including thresholds and what each one deliberately does not claim, is in the plugin repository’s docs/ folder on GitHub.