技能介绍

问题：监控状态散落在控制台里

当你的线上服务从一两个增加到十几个，UptimeRobot 的控制台会很快变成信息过载的地方。值班同学需要在多个页面之间来回切换，才能确认某个监控器当前是 Up 还是 Down；告警联系人被误删或漏配时，往往要等到故障复盘才发现。手动更新监控器的探测间隔、关键词或回调地址，也容易因为记错参数而引入新的抖动。

脚本直接调 UptimeRobot API 同样不轻松。你需要自己保管 token、处理 401 重试、维护刷新逻辑，还得为不同同事的机器做权限隔离。

它如何工作

这个技能把 UptimeRobot 的常用能力整理成 7 个原子动作，让你通过 oo CLI 直接执行：

list_monitors、get_monitor 与 get_account_details：快速盘点监控器清单、查看单个配置和账户用量
create_monitor 与 update_monitor：调整探测频率、关键词或通知策略
list_alert_contacts：核对告警接收人
delete_monitor：清理不再需要的条目

凭据由 OOMOL 服务端注入，你的本地不会接触到 UptimeRobot token。调用前先通过 oo connector schema 拉取实时的输入 / 输出 schema，再按 schema 构造 --data 的 JSON payload。响应统一是 { "data": ..., "meta": { "executionId": "..." } }，执行 ID 放在 meta.executionId 里，方便回溯。

注意点

只读动作（get / list）可以直接执行。写动作（create / update）会修改 UptimeRobot 的线上状态，执行前必须向用户确认 payload 和预期效果。delete_monitor 是破坏性的，必须再次确认目标 ID 并获得明确同意。当命令返回 401 或 scope 相关错误时，说明连接过期或缺权限，需要重新走一次一次性授权。