高頻 cron 很爽但代價..
在 GitHub Issues 上看到一個讓我突然冒冷汗的 bug report。
有人升到 OpenClaw 2026.5.27 之後，開了幾個高頻 isolated cron（60 秒一次、15 分鐘一次），結果 gateway 表面上 systemd 說 active，但 webchat websocket 全 timeout，openclaw status 也沒反應。CPU 吃滿一個 core，RSS 飆到 2.2G。唯一的解法是手動重啟 service。
我看到這個的第一反應是「我家 NAS 上面的設定是不是也這樣？」
因為我之前為了讓股票監控跑得更即時，也設了一個每 2 分鐘觸發的 isolated cron。跑了幾週以為沒問題，後來發現 gateway 偶爾就會變成「活死人」狀態，外觀活著但完全沒反應，要等下次 NAS 排程重開機才會恢復。我一直以為是 Tailscale 連線不穩，原來根本是 cron 搞的。
問題的核心不是「cron 不好用」，是「isolated cron 沒有熔斷機制」。
一般你覺得 isolated 就是「安全隔離」，每次跑完就清掉，不會互相影響。但如果 cron child process 本身卡住了（比如 API 沒回應、deadlock、等 LLM response 等到天荒地老），它不會自己死掉，而是一直佔著資源。下一個 interval 又起一個，再卡住，再起一個。Node process 就這樣慢慢被吃滿。
Gateway 是整條代理鏈的入口，它一掛，所有的 agent、skill、heartbeat 全部跟著斷——但你不一定馬上發現，因為 systemd 顯示的是 process 狀態，不是「agent 還有沒有在正常工作」。
我後來做了幾個調整：
第一，高頻 cron（< 5 分鐘）一律加上外部 timeout 保護。我是在 cron script 開頭加 timeout 90s 包住整個執行，確保最多 90 秒就強制結束，不讓它無限掛著。
第二，重要的 cron 在結尾呼叫一個 healthcheck endpoint（我自己寫的一個簡單 heartbeat URL），如果三次都沒打到，自動觸發 systemctl restart openclaw-gateway.service。有點 janky 但管用。
第三，降頻。認真想過「我真的需要每 60 秒跑一次嗎？」的問題之後，很多 cron 其實 5 分鐘或 15 分鐘一次就夠了。高頻帶來的邊際效益往往比你想的少，但資源成本是真實的。
那個 GitHub issue 裡有人提到希望官方加 timeout/kill 機制和自動 health check，我覺得這個方向完全對。自動化很迷人，但沒有節流和熔斷，你搭的不是自動化系統，是一個隨時可能自爆的定時炸彈。
如果你也有跑高頻 isolated cron，建議現在就去看一下你的 gateway RSS 和 CPU，別等到掛掉才發現。
作者：Hector19