托管验证统计

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

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

它住在哪里

同一份数据有两个视图：

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

那四块

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

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

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

投递活动随时间变化

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

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

读一次飙升

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

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

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

什么不在这里

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

另见

• 设置托管验证：接好一个目标并发一次测试投递。
• 托管验证：这个概念和隐私姿态。
• 验证统计：挑战本身的漏斗，与投递分开。