技能介绍

要解决的问题

监控探针能告诉你「某个域名挂了」，但状态页（status page）上的变化往往更复杂：服务从 degraded 恢复到 operational、维护窗口开始、分区级故障降级。运维人员真正需要的，是把这些状态转换及时推到已有的协作通道里，而不是定期去刷 UptimeRobot 的控制面板。

这个技能解决的就是这段从监控数据到告警投递的衔接：它不自己造轮子去轮询业务，而是复用 UptimeRobot 已有的探测器，把状态页上的变化事件转成 Webhook 通知。

工作方式

核心依赖 UptimeRobot 的 getMonitors 接口。技能通过该端点拉取当前 monitors 列表，对比前后两次的状态字段，识别出 宕机转换（downtime transition） 这一类关键事件，然后向预先配置的 Webhook 目标投递告警。

典型链路可以概括为三步：

调用 getMonitors 获取 monitors 及其当前状态
在状态快照之间做差分，筛出 downtime 相关的转换
通过 Webhook 把事件推送到 Slack 频道或 PagerDuty service

支持的目标端点：

Slack：适合按频道分发，便于值班轮换的团队直接在频道里看到
PagerDuty：适合需要触发 on-call 轮值和升级策略的场景

前置条件只有两条：一个 UptimeRobot 账号，以及一个可用的 API key 或 Webhook 目标地址。

适用边界与注意点

几个需要留意的地方：

事件检测依赖状态字段的对比，因此上游必须持续产出可比的快照。如果 monitors 数量很大，单次 getMonitors 的返回体也会很大，拉取频率需要在实时性和 API 配额之间取舍。
该技能只处理状态转换这一层，不负责解释故障根因，也不做历史趋势分析。如果需要聚合告警或去重，应该放在 Webhook 的下游（比如 PagerDuty 的 dedupe 策略）处理。
上游仓库并未提供可自动提取的安装与使用说明，在把这套流程接进敏感的生产工作流之前，建议先通读 UptimeRobot 的 API 文档，确认权限范围和 webhook 目标端的接收约定。

文档参考：https://uptimerobot.com/api/