原本的 Telegram Bot 只能抓到「程式自己報錯」這種問題，比較像是家裡只在其中一個房間裝了煙霧偵測器——真的出大事，例如整個電箱跳電，反而完全不會知道。容器整支掛掉、主機直接斷線斷電、排程根本沒被觸發，這三種更根本的狀況，原本完全沒有人在看，是這個專案要補的洞。
架構：三層各司其職
- Uptime Kuma：負責兩件事，一是定期問每個容器「你還活著嗎」，二是接排程任務回報的「我做完了」訊號——概念有點像登山隊的報平安機制，約好幾點要回報，時間到了沒收到訊息，安靜本身就是警訊，不用等到有人主動喊救命才知道出事。
- healthchecks.io：放在家門外的備援，專門處理「整個主機斷網斷電」這種最慘的情況——這種時候主機自己什麼訊息都發不出去，只能靠外面的人主動發現「怎麼一直沒消息」，有點像請隔壁鄰居幫忙留意，家裡是不是好幾天都沒開燈。
- alert-relay：自己寫的轉接台，把 Kuma 送來的通知統一整理再轉發到 Telegram，之後如果要接其他來源的警報，不用每個都重新串一次 Telegram 的邏輯，走同一個轉接台就好。
要不要做外部備援、通知該往哪裡送、硬碟健康度跟備份要不要另外監控，這四個決定都是一個一個討論拍板，不是隨便套一個現成方案就結束。
故障注入驗證
只確認「正常狀況下會通」不算做完，還實際測了幾件比較狠的事：
- 故意把告警轉發的對外請求指到一個打不通的地方，看它是不是真的會在該逾時的時候喊逾時，而不是傻傻等到天荒地老
- 真的把容器一個一個關掉，甚至一次全部關掉做併發測試，確認警報訊息全部有送到、沒有漏掉任何一個
- 直接去資料庫翻心跳紀錄，而不是只看程式自己回報「執行成功」就相信——畢竟自己說有交作業，不代表聯絡簿上真的有蓋章
過程中這套監控還意外抓到一個既有的漏洞：有一支容器其實建好之後從來沒有真正跑起來過。這種問題規劃階段根本想不到，是等系統真的上線盯著看之後才浮現出來的。