---
type: explanation
title: Proxy page-gate statistics
summary: Read the Proxy page-gate activity surface, what each of the four counts means, and what the passthrough-to-challenge ratio tells you about your TTL.
---

The gate keeps its own statistics, separate from a site key's [verification statistics](/docs/site-keys/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](/docs/proxy-page-gate/set-up) 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.

## See also

- [Overview](/docs/proxy-page-gate/overview) — what the gate is and the clearance cookie.
- [Set up the Proxy page-gate](/docs/proxy-page-gate/set-up) — preview mode writes to this surface before you go live.
- [Hosted verification statistics](/docs/hosted-verification/statistics) — the equivalent surface for the no-backend option.