sccache --show-stats: Verify Cache Hits
sccache --show-stats prints compile requests, cache hits and misses, and which backend is in use.
Like ccache -s, this is how you prove sccache is actually serving hits in CI. It also reports non-cacheable calls and errors, which explain a disappointing hit rate.
What it does
sccache --show-stats queries the running server and prints counters: total compile requests, cache hits and misses, forced recaches, non-cacheable calls, and any cache errors, along with the configured storage backend and its location. The server accumulates these until stopped or zeroed.
Common usage
sccache --show-stats
sccache --zero-stats # reset, then build, then show-stats
sccache --show-stats | grep -i hit
sccache --stop-server # stops the server (prints final stats)Options
| Flag / Counter | What it does |
|---|---|
| --show-stats | Print the current server statistics |
| --zero-stats | Reset counters (start-server keeps them) |
| Cache hits | Requests served from the backend |
| Non-cacheable calls | Compiles sccache could not cache (e.g. PCH, certain flags) |
| Cache errors | Backend failures (auth, network, quota) |
In CI
Run sccache --zero-stats before the build and sccache --show-stats after, so the log shows the hit rate for that run. A high "Non-cacheable calls" count points at flags sccache cannot cache (some PCH or profiling flags); a non-zero "Cache errors" points at a misconfigured or unreachable backend, not at your code.
Common errors in CI
"Failed to connect to server" means no server is running; sccache starts one on first compile, or start it explicitly. A hit rate of zero with nonzero "Cache errors" usually means the S3/GCS/Redis credentials or endpoint are wrong. Many "non-cacheable" entries are expected for link steps and unsupported flags, not a failure.