WP Redis is the Pantheon-maintained drop-in object cache backend for WordPress: install the plugin, point a constant at a Redis host, and the standard WP object cache API starts talking to Redis. There is no admin screen by design, no settings page and no built-in surface for hit rate, memory, ops or evictions. The plugin's job is to be invisible.

SleekView reads the same INFO output through the connection WP Redis already configures, samples it on a schedule into a custom table, and renders each sample as a row. Sample time, hit rate, used memory, ops per second, connected clients and evicted keys become first-class columns with sort, filter and inline action. A DevOps engineer can replace the SSH-and-INFO loop with a sortable audit, an editor can read cache health alongside posts and orders.

WP Redis continues to handle the cache on the request path exactly as before. SleekView is read-only against the INFO output and never touches the cache fill or read path, so visitor sessions are unaffected.

WP Redis is great precisely because it does almost nothing visible: it replaces the object cache backend with Redis and gets out of the way. The cost is that there is no WordPress-native surface for the cache at all. Hit rate, memory pressure, command mix and eviction patterns exist in Redis itself but are invisible from WP Admin.

Teams that care about cache health either trust the host, wire up an external monitoring stack or run INFO over SSH every time someone asks. SleekView treats the INFO output as the structured data it already is. Samples become rows with hit rate, memory, ops, clients and evictions, sortable and filterable, with sampled history persisted in a custom table.

Same headless cache behaviour, just a head bolted on for people who need to read what it is doing.