Solo 监控栈：三层检测+一条告警路的设计
B 方向·OPC 最佳实践。多批断点里一直挂着「监控 cron」——本篇把它设计完：CF Workers+LINE bot 构成需要什么监控、免费档怎么搭、告警发到哪。
背景与问题
- 见守产品的故障=「告警没发出去」——用户侧无法察觉（LINE 静默），solo 没有值班表，只能靠自动化检测。目标：所有故障在 15 分钟内被我自己知道，而不是被用户先发现。
发现
三层栈设计（2026-09-14，工具免费档规格以官网为准待核）：
层 | 检测对象 | 工具候选 | 免费档 |
|---|---|---|---|
死活（外部位） | Landing/API/webhook 端点応答 | UptimeRobot / Better Stack | 50 monitors / 5 分間隔 |
错误（内部） | Worker 异常/未处理例外 | Sentry free tier / CF Workers Tail | 5k errors/月级 |
作业心跳 | cron 任务（見守推送/eval 夜间跑/备份 rclone） | Healthchecks.io / UptimeRobot heartbeat | 死列表現（完了 ping なし=-alert） |
- 通知路由=我的个人 LINE+邮件双发：不建状态页前的过渡期；告警一本化原则（japan-notification-hub）同样适用于开发者侧。
- CF Workers 的 cron 若任务失败，Workers 本身不会告警——heartbeat 模式（作业尾部 self-ping）是唯一可靠解【事实：cron 成功与否需显式信号】。
结论
可行动启发：
- 首发日三件套上线：UptimeRobot（webhook 端点+landing）+Sentry（Worker 错误）+Healthchecks.io（3 个 cron 的 heartbeat）——全部免费档，配置 1 小时内完成，从 D-0 就有。
- heartbeat 纪律：每个 cron 作业的最后一步是成功 ping，失败路径不 ping——「没消息=坏事」的心跳语义与见守的未応答通報是同一个模式（自家吃自家狗粮）。
- 告警分级进通知ハブ：开发者告警（infra）与用户告警（見守 P0）分开路由——infra 告警只发我，不进用户通道；一个月静默测试一次（手动弄坏端点验证链路）。
- 监控配置本身入 Git：monitors 清单+heartbeat 令牌位置写进 opc-security-baseline 的恢复文档——重建环境时监控是第一批要恢复的基建。
待办 / 下次继续
关联
- 运维族：opc-launch-runbook（D-Day）× 本篇（平常时监控）× opc-incident-response-basics（障害时对应）× opc-security-baseline；断点关闭「监控 cron」（部分：栈设计完成，实装随 Week 1）。