---
type: explanation
title: 托管验证统计
summary: 读懂托管验证的投递面、每块和每条线意味着什么，以及失败的飙升在告诉你什么。
---

托管验证保有它自己的统计，与一个站点密钥的 [验证统计](/docs/site-keys/statistics) 分开。验证页回答“真人是否在通过？”；这一页回答一个更窄的问题：“我已核验的提交是否真的在到达我的目标？”它是你得到的唯一反馈，因为提交本身从不被存储，所以这里就是你注意到一个开始失败的 webhook 的地方。

和仪表盘里的一切一样，这里的数字是投递结果的聚合计数。它们绝不包含任何提交的内容。

## 它住在哪里

同一份数据有两个视图：

| 视图 | 范围 |
|---|---|
| **逐站点密钥** | 一个站点密钥的投递。从那个站点密钥打开。 |
| **逐团队** | 跨团队里每个站点密钥的投递，得到一幅全账户的画面。 |

在顶部挑一个时间范围：**今天**、**昨天**、**7 天**、**28 天**，或 **全部时间**。每块和那张图都跟随你选的范围。

## 那四块

四块标题数字合计你所选的范围：

- **Webhook 已投递**：你的 webhook 接受了的提交（它返回了一个成功状态）。
- **Webhook 失败**：Caputchin 试过但无法投递到你 webhook 的提交。
- **邮件已投递**：邮件提供商接受了的提交邮件。
- **邮件失败**：无法发出的提交邮件。

一个你没配置的目标，它那块读作零。如果你只用一个 webhook，邮件那两块就留在零，反之亦然。

## 投递活动随时间变化

这张图把那同样四个结果画在你的范围上，于是你能看到某事是 *何时* 变的，而不只是它变了。健康的托管验证看起来是那两条“已投递”线跟着你的提交量、那两条“失败”线在零附近持平。

这张图把若干底层的失败原因压成每个目标一条“失败”线，好让这条线易读。Caputchin 记录每次失败背后的具体原因供支持去调查；这些类别是：

| 目标 | 一次失败意味着以下之一 |
|---|---|
| **Webhook** | 你的端点返回了一个非成功状态、它超时了、连接本身失败了、或它的 URL 在投递前被阻止为不安全。 |
| **邮件** | 邮件提供商拒绝了这条消息、对它的调用失败了、或服务器上没配置邮件发送。 |

## 读一次飙升

任一条“失败”线的突然跳升就是该行动的信号，而原因几乎总在目标这一侧，不在 Caputchin 这一侧：

- **Webhook 失败在爬升。** 你的端点宕了、慢了（投递几秒后超时）、在返回一个错误状态、或已经搬到一个现在看起来不安全的 URL 了。检查端点在一个公开的 `https` URL 上是否在线且可达，并在你修好它之后发一次新的 [测试投递](/docs/hosted-verification/set-up) 来确认。
- **邮件失败在爬升。** 那个地址正在下游被拒绝，或邮件投递暂时不可用。确认目标地址，并用一次测试投递重试。

因为一次失败的投递不会被重试，一段失败的窗口就是一段没有到达你的提交的窗口。那就是要盯着这一页、而不是假定沉默意味着风平浪静的原因。

## 什么不在这里

- **没有提交内容。** 这一页计数结果，绝不计数载荷。如果你需要一份提交了什么的记录，就在你 webhook 的接收端存它。
- **没有逐访客数据。** 和 Caputchin 其余部分同样的姿态：无 IP、无指纹、无身份。

## 另见

- [设置托管验证](/docs/hosted-verification/set-up)：接好一个目标并发一次测试投递。
- [托管验证](/docs/hosted-verification/overview)：这个概念和隐私姿态。
- [验证统计](/docs/site-keys/statistics)：挑战本身的漏斗，与投递分开。