OpenClaw Gateway は稼働中なのに、定時サマリー・キャッシュ掃除・モデル残高チェックを個人の crontab や外部オーケストレータに任せた場合、Gateway アップグレードや systemd 再起動後 にジョブがサイレントに消えることがある一方で channels status --probe は正常に見える。本稿は運用視点で、openclaw cron とメッセージ経路を分ける隠れた七つの前提、組み込み／ホスト crontab／外部スケジューラの対照表、そして cron status・cron list・doctor とログまでの六段チェックリスト を示し、チャネルプローブと dmPolicy・本番監視／アップグレードRollback・リモートモードと設定ドリフト と役割分担で読めるようにする。
公式FAQは openclaw status → gateway status → channels status --probe と書かれがちだが、定期実行はリリースノートに一行しかなく、本番では「誰がトリガしたか分からない線」になりやすい。次の7つで「Cronが壊れた」から「どの経路が欠けたか」に議論を戻す。
無音のcronをチャネル障害と混ぜる：セッションに届かないコールバックと Telegram/WhatsApp 入信は別。チャネルプローブの分岐表を見てから crontab を弄る。
ユーザー不一致で設定：launchd / systemd --user とSSHログインが違うと「手では動く／再起動後に消える」になる。
OPENCLAW_STATE_DIR ドリフト無視：プロファイル／マウントずれで状態が二重化し、Cronだけが別ディレクトリを見て空リストに。
アップグレード後に gateway install --force をしない：CLI/サービス分裂と同様、古いパスを指し続けることがある。
重いジョブを軽量キュー語りに混ぜる：ヘルスチェックと全インデックスを同居させるとイベントループが飢える。分割とバックオフ。
cron失敗に固有のログラベルがない：本番監視稿と同じく、ジョブ名でフィルタできないとトリアージが爆発する。
リモートモードとノートPC crontabを混在させ入口を書かない：gateway.mode=remote では周期実行は実Gatewayホスト側。ノートの crontab は擬似バックアップに見えるだけ。リモート稿で確認。
根は「エージェントが動く」と「定時オペが信頼できる」を同一視すること。OpenClawはモデル・ツール・チャネルを Gateway に集約するので、プラットフォーム側は観測可能なスケジュール契約が要る。
Gatewayを専用クラウドMac で24/7載せる検討があるなら、この稿とCloud Mac系を併読すること。スケジュール安定はスリープ設定に強く依存する。
組み込み cron に物足りなさを感じるなら、「マシン横断オーケストレーション」か「Gatewayと同じライフサイクルのハートビート」かを先に決める。前者だけが Kubernetes や systemd timer の価値になる。
トリガが Gateway状態と同源か／失敗時に同一CLIで跡が取れるかで選ぶ。銀の弾はない。
| 観点 | openclaw cron（組込） | システム crontab / launchd | 外部（K8s CronJob 等） |
|---|---|---|---|
| IDとPATH | Gateway と同一サービスユーザーで最も安定 | ログインシェルと別れやすく env ファイル前提 | PodとホストGatewayが離れSecrets同期が重い |
| アップグレード影響 | Gateway版に連動／リノート読みながら再検証 | OpenClaw自動移行なし／旧パスが撃ち続ける | イメージとHelmそれぞれで変更運用が二系統 |
| 可観測性 | cron status / list が logs と同義 | stdout転送が自前 | クラスタ指標がGatewayから切れる |
| 適例 | エージェント／チャネルに強く依存する軽い周期処理 | ホストバックアップなどベンダ中立スクリプト | サービス横断バッチ・別NS |
本番の「cronとは」ここではアップグレード翌朝に三コマンドでまだ効いていると言い切れるか。
openclaw health --json に cron 項目バージョンを混ぜ、Prometheus側は「期限切れのみ」のシグナルに寄せる。
本番監視稿 と連動させ、Rollback表に一行「変更前後で cron list の件数が同じ」を足す。
並びは Gatewayが先、その次に登録、最後に通知。細かい文言は使用中のビルドに合わせ、ここは診断順番のみを固定する。
Gatewayを固める：openclaw gateway status でRuntimeとRPCがOKになるまでcronを書かない。
サービスユーザーでメンテ作業：TTY環境だけに依存しない。
最小ジョブ：ログ一行やマーカーを触るだけ、確認のためだけに周期を短縮。
openclaw cron status と openclaw cron listで名前／次実行／Enableを突き合わせ。
意図的に openclaw gateway restart。直後にもう一度04。無ければユーザーと状態ディレ優先。
変更チケットに：openclaw doctor出力を添付。
openclaw gateway status openclaw cron status openclaw cron list openclaw doctor openclaw logs --follow
ヒント：同一ホストで Tailscale Serve やトンネルを併用するなら Tailscale経路稿 と整合を取り、ヘルスプローブが別インスタンスへ当たろうものならcronログだけは綺麗でも副作用が出ない。
重量ジョブ導入前に重ね実行ルールを書く。cronより周期が長いときに積む負荷は別原因。
外向きHTTPにはタイムアウトとTLS検証を明示。暗黙のデフォルトに頼るとネットの揺らぎまでOpenClaw退行と誤認する。
公式Playbookが cron status / list を後ろに置くのは、未実行の半分はGateway未準備か設定ドリフトだから、という理由。推奨：gateway status → cron status/list → channels status --probe → 長めのログ追跡。
cron list の next が延び続けるときは、「スケジューラ背圧」（大量エージェントキュー）と「時計ジャンプ」（スリープ復帰・NTP追従など）で分離する。
doctor が meta.lastTouchedVersion とバイナリを食い違わせているなら、公式の手順どおり PATH/gateway install --force を先。cron一覧に並んでいても実行層だけ拒む半壊状態が出る。
注意：ディスク空きを確認しないまま並列クリーンジョブで全会話ツリーを掃けば IOが飽和し、RPCだけ一瞬だけ緑に見える一方でタイムアウトが連鎖する。
警戒閾値：重要項目は「最終成功時刻」ベースで2周期超なら昇格。その他はログ存在チェックだけに。
リモートモード と併用するなら、ノート／サーバ双方で cron list を揃え、どのGatewayホストがスケジューラかを固定する。
運用での閾値は頻度を見て調整する。
gateway install --force→gateway restart→本稿の診断列と cron list をスナップショットで比較。cron status が静か ⇒ P1 扱いで openclaw logs --follow。単体のホスト crontab では Gateway とライフサイクル同源になりにくい。外部のみだと監視ダブってアップグレード夜だけ「どちらが叩く」と消える。常時オンでディスク／ネットSLAが読める専用リモートMac に Gateway と cron を載せつつ openclaw 系を単一運用すると楽になるケースも多い。NodeMini クラウド Mac Mini：レンタル料金 と ヘルプセンター で仕様確認。
関連記事は OpenClawカテゴリで絞り込み。導入→安全→監視→チャネル→リモート→cronの順での追い方が読みやすい。
組み込みは Gateway と状態ディレクトリをまとめて扱え、アップグレード後も同じ CLI で検証できます。ホスト crontab は PATH や OPENCLAW_STATE_DIR がサービスとずれやすいです。関連は OpenClaw カテゴリ から。
openclaw gateway status のあと openclaw cron status / cron list、次に openclaw doctor。まだならログ。マシン側の案内は ヘルプセンター。
メッセージ経路へ。openclaw channels status --probe とペアリングを確認し、チャネルプローブと dmPolicy を読む。クラウド Mac へ載せ替えるなら先に レンタル料金ページ。