Proxy page-gate statistics

The gate keeps its own statistics, separate from a site key's verification statistics. The verification page answers "are real people getting through the game?"; this page answers a narrower question: "how often is the gate challenging visitors versus letting a cleared visitor pass?" It is how you confirm the gate is wired and tuned, and it is the same surface preview mode writes to while you are still testing.

Where it lives

There are two views:

Per site key — the Proxy statistics page under a site key, for one gated origin.
Per troop — the Proxy statistics page at the troop level, aggregated across every site key in the troop.

Both need the Alpha plan or higher; below that the page shows an upgrade card instead.

The four counts

Every gate decision is recorded as one of four kinds:

Passthrough — a request arrived with a valid pass and was allowed. This is the win condition; a cleared visitor browsing the site generates these.
Challenge served — a request had no valid pass, so the visitor was sent to the game.
Pass issued — a visitor solved the game and a pass was minted (the callback then set the cookie).
Denied — the authorizer rejected the request under a fail-closed policy while it could not confirm a pass.

The passthrough-to-challenge ratio

The headline number is passthrough relative to challenges. Once visitors are clearing the gate, most of their requests should be passthrough, with a challenge only at the start of a visit or after a pass expires. A high passthrough ratio means your Clearance TTL is doing its job, one solve is buying many requests. If challenges stay high relative to passthrough, the TTL may be too short (visitors re-challenged mid-session) or the cookie is not being set (check the callback).

Reading it during rollout

While preview mode is on, watch for the sequence in a single test visit: one challenge_served (no cookie yet), then a pass_issued after you solve, then passthrough climbing as you reload. Missing challenges mean the authorizer block is not being hit; a pass_issued that never turns into passthrough means the cookie is not sticking.

Retention

History is retained by plan tier and older buckets are pruned on a daily schedule, so the window you can look back over widens with your plan. The live ratio and recent activity are always available.

What is not here

No fail-mode-open passthroughs from your proxy. When your proxy is configured fail-open and Caputchin is unreachable, the proxy lets the request through on its own; Caputchin never sees it, so it cannot be counted here.
No per-visitor data. Counts only, no IP, user agent, or request contents, in keeping with Caputchin's privacy stance.