為什麼我把排程從本機搬到雲端，又加了一隻看門狗
我的籌碼系統每天要在固定時間自己醒來、抓資料、算訊號、推播。一開始我以為這是「寫一行 cron 就好」的小事。結果它教了我三課。
第一課：本機 cron 會睡著
我本來想用 macOS 的 cron 排每日任務。順口問了一句：「這樣電腦不就要一直開著？」——這一問問出真相：cron 在電腦睡眠時跳過就跳過了，醒來不會補跑。 對一個「每天都要跑」的任務，這是致命的。改用 launchd（至少醒來會補一次）才勉強堪用。
第二課：託管 cron 是 best-effort
於是我把排程搬上雲端，用 Cloudflare Worker 的 cron 去觸發 GitHub Actions。穩多了——直到某一天，它一天漏了兩班。查下去才確認：Cloudflare 的 cron 排程是 best-effort，它會靜默跳過，而且不會告訴你。
我直接 POST 打 Worker 的 HTTP 端點測試，回 {ok, 204}——程式跟 token 都健康。所以問題不在我的程式，是託管排程器本身偷懶。
第三課：最安靜的失敗，是「整次沒被觸發」
這裡有個魔鬼細節。我原本的失敗告警只在「有跑但失敗」時通知。但「整個沒被觸發」＝ 0 個 run ＝ 0 個失敗 ＝ 不會告警。系統壞了，卻一片祥和。
解法是一隻 dead-man’s switch 看門狗：用 另一套基礎設施（GitHub 原生排程，刻意跟主觸發不同家）在每天的截止時間檢查「今天到底有沒有成功跑過」，沒有就喊我。
關鍵不是「讓它不會壞」，而是「壞了我一定會知道」。
最後我把它搬到最可靠的地方
後來我索性把觸發搬到一台本來就在跑真實交易的 24/7 常駐機器上——一個永遠醒著、自己看時間的長駐進程，比任何 best-effort cron 都可靠。看門狗仍留在另一套基礎設施上補位。
兩件事我帶走了：可靠度是工程問題，不是寫對一行 cron；以及監控的價值，在它沉默的那一天才會兌現。