Open the terminal dashboard:

kache monitor
kache monitor --since 1h

The monitor attempts to start the daemon for transfer statistics. It still reads the local store and event log if the daemon is unavailable.

Header

Tabs

1. Build lists the builds the event log has seen, newest on top and running ones first, and shows the selected build's compiler events with outcome, action, timing, and size. The panel title carries the build's cost strip: compile time saved, compile time spent in misses, and kache's own overhead.
2. Why explains the selected build. Misses are collapsed to their causes, most frequent first: a failed store or a rejected lookup (a caching failure to fix), a dependency cascade named by the crate that actually changed, the crate's own changed inputs, no earlier compile in the loaded history, or unexplained. Passthroughs are grouped by reason, with queries such as --print kept apart from compiles. Crates that keep missing across builds of the same tree are listed as chronic, and every passthrough in the build is listed at the end. The whole tab is one body; PgUp and PgDn scroll it.
3. Projects lists observed target directories and disk use. Press r to rescan.
4. Store lists cache entries. Press s to change sort order.
5. Transfer shows recent remote uploads and downloads.

A build is every event sharing the session id the wrapper mints per cargo build. Events from older wrappers have no id and are grouped by build root, split at idle gaps of five minutes. Those builds carry a ~ after their name.

Cascade causes need per-dependency digests on the events, which [cache] explain_miss = true records. Without it the Why tab says so. Every figure on the tab describes the loaded history: with --since, a crate whose last compile is before the cutoff reads as having no earlier compile.

dup means the compiler ran after a key miss but produced blobs already in the store. It is not a cache hit. A passthrough is not a miss either: kache never consulted the cache for it.

Keys

q, Ctrl+C         quit
p                 pause and resume (the log keeps its place; nothing is lost)
Tab, Shift+Tab    next and previous tab
1 2 3 4 5         select a tab
Up / Down, j / k  on Build and Why: pick a build; elsewhere: scroll one row
Enter             on Build: open Why for the picked build
PgUp / PgDn       scroll one page
Home / End        first and last row; End on Build follows new events again
f                 filter the current supported tab
s                 change Store sort
c                 clear Build events
r                 rescan Projects

Above the top build is "following the top build": the monitor starts there and returns there when you press Up past the first row. The top build is the newest running one, or the newest finished one when nothing is running.

Clicking a tab title selects it and the mouse wheel scrolls the current panel.

The Lookups strip under the Build events is a clock: one column per slice of the last five minutes (or of the --since window), hits above misses on a shared scale, so a quiet minute is flat and a burst is a burst.

Narrow terminals drop the least important columns first instead of clipping every column. Below 60×16 the monitor says so and points at kache stats, which prints the same numbers as text and works in a pipe.

Triage

• Daemon offline: run kache daemon status and inspect kache daemon log.
• Store near its limit: run kache gc. If cloned outputs keep entries in place, preview stale targets with kache clean --tracked --stale 14d --dry-run.
• No remote activity: check daemon state, credentials, and kache doctor.
• Unexpected misses: run kache why-miss <crate>.