WP REST Cache sits in front of every wp-json request, stores the response and serves a cached copy until invalidation. The plugin's admin lists cached endpoints with a hit count column, which is fine for a sanity check and weak for the question backend leads actually ask: which entries are about to expire, which were last served two hours ago, and which routes never warm at all.

SleekView reads the cache_entries table the plugin writes (or the wp_options transients on smaller installs). Endpoint, cache_status, hit count, response size, expires_at and last_served become real columns. A backend lead can filter to cache_status = miss and sort by hit count to see the routes that bypass the cache hardest, or filter to expires_at within the next hour to predict origin load.

WP REST Cache keeps owning invalidation and the request-time cache decision. The table view owns the audit surface, so dead entries, hot routes and cache-bypass patterns stop hiding inside a paginated log.

Caches fail silently. Every response still returns the right data, the only thing that quietly changes is origin load and response time. Without an entries table, the conversation about cache health stays qualitative: someone insists it's working, someone else insists it's not, and nobody has the rows in front of them.

SleekView reads the cache_entries store WP REST Cache already maintains and renders it as a working table. Backend devs sort by miss count, DevOps sort by expires_at, invalidation owners sort by last_served. The plugin keeps owning the cache decision.

The table view owns the audit surface, so cache behaviour stops being something only the plugin's internal state can see.