为什么未认领的 server 每 12 小时探测一次

本文译自 2026-09-23 的英文原文。

每个报告页都写明这个 server 处在哪个检测周期。数字是 12 小时、8 小时和 15 分钟。哪个都不是随便定的，哪个也都不是对两次探测之间所发生事情的承诺。

没人请我们检查的 server：12 小时

未认领的 server，是维护者还没有露面的 server。通常是我们在公开登记册里找到它、读过它的 robots.txt，然后像任何客户端都能做的那样观测它。这是正当的，同时也意味着我们是客人。客人不会每十五分钟敲一次门。

12 小时是还能给读者提供有用信息的最慢节奏：

• 一天两次探测，白天黑夜都能碰上。 两次相隔十二小时，所以一台只在某人上班时间在线的 server，每天都会错过其中一次；而有一次探测没得到应答的那一天，绝不会显示成一个干净的日子。
• 足以看到工具集的变化。 未认领 server 上的工具集和 schema，变化的尺度是一次次发布，而不是几分钟。一天取两次指纹，变化发生后半天之内就会被记下；对一台还没认领的 server 来说，这个精度已经够用。
• 负载小到可以忽略。 每次探测只有寥寥几个请求。目录里每个条目每天两次，比任何 server 自己的存活检查产生的背景流量还低；一台主机上如果收录了好几个 endpoint，每个 endpoint 各是这个量。

目录里显示的可达率（已观测日）是这样算的：窗口从「我们第一次观测到这台 server」和「90 天前」两者中较晚的那天开始；在窗口内能判定的天数里，endpoint 对我们每一次探测都有应答的天数所占的比例。某一天只要有一次探测没有得到应答——域名无法解析、连接失败（自 2026-09-27 起计入）、或在探测时间预算内没有收到完整响应——或者（自 2026-09-23 起）握手得到的是 5xx 应答，这一天就算作未应答。如果某一天没能得出结论的探测全是我们自己造成的——我们被限速了，或我们自己的策略拒绝连接——这一天就不计入，和我们根本没去探测的日子一样。我们把它显示为整数百分比，旁边标着计算所用的天数。

维护者来了之后：8 小时

认领后的 server 在 Free 档改为每 8 小时一次。维护者已经证明自己控制这个 endpoint，并要求被检查，我们就不再是客人了。一天三次探测，在指纹变化多快能显示出来、一次短暂中断当天被看到的可能性这两方面，都是实打实的提升，但又不至于变成监控。

Indie 档：15 分钟

Indie 档面向希望探测器像 CI 流水线里的契约测试那样工作的人：频率要高到足以在下一次发布之前，抓住一次弄坏握手的发布，并让一次改动了工具 schema 的发布显示出新的指纹。15 分钟是我们目前提供的最短间隔；在这个间隔下，故障邮件会在那次发布还新鲜的时候到达你手里，而不是几个小时之后。

检测节奏不代表什么

方法论页上最重要、也最常被跳过的一句话是：我们不保证 endpoint 在两次 run 之间的行为。 一台 15 分钟周期的 server，可以宕机 14 分钟，记录上却一次中断都没有。一台 12 小时周期的 server，可能有一个糟糕的下午，而我们根本看不到。报告展示的是我们什么时候看了、看到了什么。把它读成持续监控，就是读出了它没有的东西；页面的写法就是要让人很难这样读。

付费会把你的 server 换到更快的周期。它不改变任何一次探测观测到什么，也不改变任何一行如何判定。除了周期，付费买到的是更多可认领 server 的名额（每份订阅 10 个，而不是 1 个），以及一个实时的 README 徽章而不是静态的；此外什么都没有，这是有意的。有一个副作用值得知道：目录默认按最近观测时间排序，最新的在前，所以每 15 分钟检查一次的 server 往往排在靠前的位置。这是排程带来的结果，不是排名。

关于排程本身

探测器每五分钟醒来一次，领取到期的 server，每次醒来最多领取固定的数量；剩下的等之后几次醒来，每五分钟再领一批。我们发现的 server 被分配了分散在各轮里的起始时间，这样负载摊在一整天里，而不是在午夜一下子涌来。如果 server 要求我们放慢，回 429，或者回带 Retry-After 头的 503，我们会照办：停止这一轮；它的下一次探测，绝不会排在它以秒数给出的延迟之前（上限 24 小时）；没跑的检查显示为未检查（Not checked）并写明这个原因，而不是未通过（Failed）。做一个有礼貌的客户端是方法论的一部分，不是运维细节。