Give it an address. It will tell you:

whether that address can be cached, and if not, which rule stopped it and what that rule means;
the cache reference, and the address the page is stored under;
whether a copy is on disk and how old it is;
and then it fetches the page twice and reports what the server really did, because a rule saying a page is cacheable and a server proving it are two different claims.

Every page the cache handles carries an X-NimbleCache response header: HIT or STALE when it was served from the cache, MISS when it was built and stored, and BYPASS followed by the reason when it was not stored. When the page set a cookie, the header names it: BYPASS set-cookie (xyz_visitor), or BYPASS no-store (PHPSESSID) for a page that started a PHP session, and so does the Diagnostics sentence. That header is how Diagnostics can name a rule that is only checked while the page is being built — the cart, a Rules-screen choice, another plugin's trnc_bypass — rather than calling the page cacheable.

The two fetches also say what else answered. When the response carries a header another cache sends (cf-cache-status, x-varnish, x-cache, x-kinsta-cache, x-litespeed-cache and others), Diagnostics quotes it as it came, for example "A second cache sits in front of NimbleCache: Cloudflare (cf-cache-status: HIT)", and says whether NimbleCache asks it to clear pages, or why that cache clears nothing when it does not. A host's cache behind Cloudflare that only sends x-cache, x-cache-status or x-proxy-cache is reported too, with its header quoted, though such a header does not say whose cache it is. It is counted as cleared only while a plugin that clears a host's own cache is active (Nginx Helper, Proxy Cache Purge, SiteGround Speed Optimizer, Breeze, or WP Engine's own), and never because Cloudflare's plugin, Kinsta or LiteSpeed Cache is active, since each of those names its own cache in a header of its own (QUIC.cloud, which LiteSpeed Cache clears, sends x-qc-cache, and is named). Otherwise Diagnostics says NimbleCache cannot clear it, and the Dashboard shows its warning. CloudFront, which writes its name into x-cache, is named, and NimbleCache cannot clear it. WP Engine's x-cache: HIT: 19 is read as its stored copy. When that other cache answered the second fetch itself, what the fetch says about NimbleCache comes from the copy it stored, and the note says so. With no such header it says nothing about one. It can only see a cache the site's own request passes through: a host that sends the site's requests to itself directly shows none, even when visitors go through one.

The same screen reports the state of the fast path, the cache directory, and whether anything about the server needs knowing.