WP REST Cache sits in front of every wp-json request, stores the response and serves cached copies until invalidation. The plugin's admin lists cached endpoints with a hit count column, which is useful for sanity but does not answer the questions a backend team actually asks. What is the real hit rate? Which endpoints miss the most? Are expirations happening on a healthy cadence or are entries getting flushed by an aggressive invalidation hook every time a post saves?

SleekView Charts reads the cache-entries table the plugin writes (and the underlying transients on installs that route cache entries through wp_options). A Number card shows total hits in the last day. A Pie splits hits against misses for a single, honest hit-rate KPI. A Bar groups requests per endpoint so the API team sees which routes carry the load. An Area trends expirations per hour, which is the clearest test of whether invalidation rules are sensibly tuned or overzealous.

Everything reads from the same data the cache uses to decide hit or miss. There is no proxy, no separate APM, and the dashboard works on every install that has WP REST Cache active.

Caches fail silently in the worst possible way. Everything still works, every response still returns the right data, the only thing that quietly changes is origin load and response time. Without a hit-rate chart, the conversation about cache health is qualitative and political: someone insists it's working, someone else insists it's not, and nobody has a number.

A KPI for total hits anchors the discussion. A hit-miss-bypass pie gives the real percentage. A bar of requests per endpoint shows where the load actually is, which is rarely where the team thought.

An expirations trend tells you whether invalidation is the right shape or the wrong shape. Same plugin, completely different operational confidence.