# Integration health and analytics

> The console's checks that your integration works (is your server verifying tokens?) and its challenge analytics, with what each number means.

Each site in the console has an **integration health** panel and an
**analytics** view. Both are computed from AgentGate's decision events
(browser verifications and gateway checks) and hourly counters of siteverify
answers and refused origins. The same data is available from the API:
`GET /v1/console/sites/{siteKey}/health` and `…/analytics` (operators:
`/v1/admin/sites/{siteKey}/…`).

## Integration health

Health looks at the last 24 hours and reports typed checks, each with a
severity (`ok`, `info`, `warning`, `critical`), a title, a detail and a
suggested fix. The site's overall status is its most severe check.

| Check | Severity | When |
| --- | --- | --- |
| `siteverify_missing` | critical | the widget issued tokens but AgentGate received no siteverify call or gateway check for them, and no backend secret was used |
| `siteverify_missing` | warning | at least 10 tokens were issued and server checks cover fewer than half of them |
| `no_credential` | warning | the site has no live backend secret, so your server cannot call siteverify |
| `not_installed` | info | AgentGate has never seen a request for the site |
| `no_traffic` | warning | the last request was more than 24 hours ago |
| `origin_not_allowed` | warning | pages on origins not in the site's allowed origins tried to use the site key (the evidence lists the origins) |
| `siteverify_errors` | warning | at least 5 siteverify calls failed and they are at least 20% of all siteverify calls (the most common error code is named) |

> [!IMPORTANT]
> `siteverify_missing` is the one to act on first. A token that your server
> never checks protects nothing: the form is open to anyone who posts to it
> directly. See [Validate tokens](/docs/siteverify).

`origin_not_allowed` can be harmless: if the listed origins are not yours,
someone embedded your public site key elsewhere, and the widget was refused
there as it should be.

## Analytics

Analytics cover a range (the last 24 hours by default; `from` and `to` on
the API), in hourly or daily buckets, with totals and a time series.

| Number | Meaning |
| --- | --- |
| `issued` | verifications started |
| `solved` | tokens issued: `solvedInvisible` + `solvedAttested` + `solvedInteractive` |
| `unsolved` | `issued` − `solved`: failed checks, declined, errors and abandoned checks |
| `solvedInvisible` | passed without a visible check |
| `solvedAttested` | passed after a Private Access Token attested the device |
| `solvedInteractive` | passed the press-and-hold or wait check |
| `shown` | the visible check was shown |
| `failedStep` | the visible check was answered but failed |
| `declined` | refused by the rules without a check |
| `abandoned` | the check was shown and never answered |
| `solveRate` | `solved` / `issued` |
| `siteverifyValid`, `siteverifyInvalid` | your server's siteverify calls that succeeded or failed (`siteverifyByCode` splits the failures by code) |
| `clearanceReuse` | gateway requests admitted by a clearance instead of a new token |
| `wouldChallenge`, `wouldBlock` | monitor mode: tokens issued that enforce mode would have challenged or blocked |

Top lists show the page origins, browser engines, countries and widget
modes the verifications came from.

### Likely human

`likelyHuman` is an **estimate**, between 0 and 1. It considers only first
verdicts of browser verifications (passed without a check, device-attested,
shown the check, or declined) and reports the share that passed without a
visible check **and** that enforce mode would also have passed. It is not a
count of people: an automated browser that passes silently counts as
"likely human", and a person who was shown the check does not. Interactive
widgets always show the check, so it reads low for them.