排程存在，不代表任務還會跑
上週看到 r/openclaw 有篇討論，OpenClaw 2026.9.6 讓作者的 cron jobs 全部失效。他平常習慣快速更新，這次卻卡在很難定位的狀態，最後只能退回 2026.9.4，或等 9.7。留言有人建議升級前先查 GitHub issues，也有人請外部 coding agent 協助。
我覺得最值得記住的是，設定檔裡看得到排程，不等於排程仍然具備執行能力。這件事放到任何自動化系統都成立。
先做最小驗證
以前維護 SaaS 時，我們有一個每天凌晨 2 點整理報表的 job。某次 dependency upgrade 後，dashboard 仍顯示 active，下一次執行時間也填好了，結果連續三天沒有寄出報表。最後發現 worker 讀到另一份環境變數，job 存在，process 卻沒有連上同一個 queue。
我的第一個做法是升級後立刻做 smoke test：列出 job，確認 schedule、timezone、enabled 狀態；手動觸發一次；再等一個可觀察結果，例如 webhook、檔案或帶時間戳的 heartbeat。
openclaw cron list
openclaw cron run daily-report --wait
openclaw cron runs daily-report --limit 1
指令名稱可能依版本不同，原則是留下「我確定它跑過」的證據。把結果和版本一起記下來，例如 openclaw_version=2026.9.6，出事時才不用靠猜。只看 UI 的綠色勾勾，跟看咖啡機亮著就以為咖啡煮好了一樣危險。
把觀測從排程狀態拆出來
第二個做法是分開追蹤三件事：有沒有註冊、有沒有觸發、有沒有完成。重要 job 至少留下最後成功時間、執行耗時、失敗次數，並設定稍寬於執行頻率的 alert。每 15 分鐘跑一次的任務，連續 30 分鐘沒有成功就通知。
只監控程序存活不夠，活著但不做事的 worker，最容易讓團隊在隔天早上對著空報表喝冷咖啡。
讓回滾成為升級步驟
第三個做法是先保存版本、設定與最近一次成功紀錄，挑一個非關鍵 job 做 canary，連續跑過 2 次再擴大。升級後 10 分鐘內沒有通過 smoke test，就回到上一個已知可用版本。
回滾要在平常就演練，事故發生時才不會臨時研究降版方式。2026.9.6 的案例提醒我，自動化可靠性來自每次變更後都能用低成本證明它還在工作。更新可以快，驗證、觀測和回滾要跟上。
作者：咖啡驅動開發