如果你每月为PagerDuty支付21到41美元，正打算找个开源替代方案自建系统，现在可能要重新评估这个计划了。我们对三个主流自托管PagerDuty替代方案的健康状况做了最新排查，结果是零存活。

上周的首份仓库健康快照显示，约11%的自托管替代方案已停止维护。本周我们聚焦单一品类中受影响最严重的领域：值班轮换与事件告警。这个数字不是11%，是100%。

打开网易新闻 查看精彩图片

以下是2026年5月的真实状况，以及替代方案失效后的应对思路。

Grafana OnCall：两个月前归档

最令人意外的案例。Grafana在2026年3月24日归档了自家的值班项目。仓库README指向"Grafana IRM"——Grafana路线图上重新命名的继任产品。截至2026年5月，IRM是Grafana Cloud的付费功能，不提供自托管版本。

对自建用户这意味着：代码库冻结，不再接受PR，新功能全部锁在SaaS付费墙后。这个陷阱难以察觉，因为仓库仍有近期提交——归档发生在最后一批修复冲刺之后。仅看last_commit_at的工具会误判OnCall状态良好。真正有效的信号是archived: true标志。

选型教训：最后提交时间只是判断标准的一半，另一半是归档标志。我们快照中约三分之一的"死亡"仓库正是死于archived: true，而非提交停滞。

LinkedIn Oncall：九个月静默

LinkedIn的Oncall从来就不是完整方案。它只负责值班轮换和日历层，实际告警需要搭配linkedin/iris使用。双进程架构，MySQL底层，2018年风格的界面。如果能持续维护，这些妥协尚可接受。

现实是没有维护。九个月零提交，对于一个需要跟进Twilio API版本、Slack Block Kit修订、Prometheus AlertManager Schema变更的工具来说，这是实质性风险。未解决issue共78个。iris部分（linkedin/iris）同样陷入停滞。

这是典型的"收购式人才流失型放弃"：内部团队在某位维护者任职期间保持项目运转，人员轮岗后就不再触碰。非恶意，非正式死亡——只是无人掌舵。

Cabot：仓库已消失

cabotapp/cabot今天从GitHub API返回404。重命名、删除或转入私有命名空间——我们无从确认具体原因。

Cabot曾是三者中部署最简单的：Pingdom加告警功能，只需Postgres和Cabot本身。最小化架构对小团队极具吸引力。但api.github.com/repos/cabotapp/cabot返回404意味着无法克隆、无法fork、无法访问历史issue追踪。其中积累的知识——对自建用户而言——已不可获取。

目录失效的结构性问题

三个项目，三种不同的死亡形态，却指向同一个核心困境：开源工具目录的维护滞后于项目实际状态。归档标志、提交频率、issue响应速度——这些信号分散在不同数据源，人工跟踪成本极高。

对于依赖自建方案控制成本或满足合规要求的团队，当前选择空间正在收窄。Grafana OnCall的SaaS化转型、LinkedIn的内部维护模式、Cabot的彻底消失，分别代表了企业开源项目的三种终局路径。

2026年的实际选项

如果自建路线受阻，评估维度需要调整：付费SaaS的API可导出性、数据驻留合规条款、以及——最关键的——当供应商策略转向时，迁移成本的可控性。PagerDuty的定价之所以成为行业基准，部分原因在于其生态锁定效应。现在寻找替代方案，需要把"供应商未来五年的战略稳定性"纳入核心评估指标，而非仅比较当前功能清单和价格。