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 check.
• Pass issued — a visitor completed the check and a pass was minted (the callback then set the cookie).
• Denied — a request arrived carrying a pass that was not valid: expired, tampered with, or issued for a different site key. A first visit with no cookie at all is not counted here; that shows up as a challenge.

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 pass the check, 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.

Counts are close, not exact

Gate outcomes are batched before they are written, so a counter can lose a few events if the edge recycles mid-second. Ratios and trends are reliable; treat an individual count as very close rather than exact, especially on a quiet site.

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 passthroughs or blocks from your proxy. Fail-open and fail-closed are decisions your proxy makes when it cannot reach Caputchin. Caputchin never sees those requests, so neither outcome appears here, in either column.
• No per-visitor data. Counts only, no IP, user agent, or request contents, in keeping with Caputchin's privacy stance.

See also

• Overview — what the gate is and the clearance cookie.
• Set up the Proxy page-gate — preview mode writes to this surface before you go live.
• Hosted verification statistics — the equivalent surface for the no-backend option.