2026 OpenClaw スケジュールと無人運用：openclaw cron、タイムゾーン、失敗復旧（リモート Mac 常駐 Gateway）

Why “the bot replies” does not imply “cron is safe”

1. Missing health baselines: silent failures when disks fill or permissions drift.
2. Timezone skew: mixing local crontab semantics with UTC CI causes double or missed runs.
3. Overlapping schedulers: systemd timers and OpenClaw jobs hammering the same script without locking.

Pre-flight matrix before enabling cron-style jobs

Make “ready to schedule” an explicit gate, not a default.

Minimal loop: list, enable, verify, rollback

Assume your build ships openclaw cron subcommands aligned with community docs (cron list, cron status). Order: list → status → enable one job → watch one fire → document. Capture stdout for upgrades.

Timezones: author in UTC, read in local

Store schedules in UTC; print offsets in logs. For “09:00 weekday” rules, name the city whose 09:00 you mean.

Cold start after Gateway restart

Verify process, registrations, and last-fired timestamps. If timestamps stall, inspect disk and permissions before blaming the scheduler. Cross-read the Gateway troubleshooting runbook.

Dedicated remote Mac topology

Laptops sleep; servers should not. Colocating Gateway and scheduled jobs on dedicated Apple Silicon removes power-policy noise. See the unattended launchd/systemd checklist.

Split duties with OS cron

Use OS cron for machine hygiene; use OpenClaw schedulers for tasks that need session context and channel credentials. Serialize with locks if both touch the same script.

Six-step rollout

1. Pin versions and config paths.
2. Run doctor and gateway status.
3. List jobs with owners and alert routes.
4. Enable a low-frequency probe first.
5. Raise frequency while watching disk/CPU.
6. Keep a one-command disable and last-known-good snapshot.

openclaw gateway status
openclaw doctor
openclaw cron list || true
openclaw cron status || true
openclaw logs --follow

Three SRE metrics

• Last successful fire vs SLA skew
• Retry budget with exponential backoff for third-party APIs
• Log growth MB/h per job

Why OS-only cron is usually insufficient

OS cron lacks first-class awareness of OpenClaw session state and channel tokens; upgrades can silently break wrapper scripts. MACCOME dedicated remote Macs give stable power, disks, and regions so Gateway plus schedules stay boringly correct.

ジョブ分類：プローブ、ハウスキーピング、業務フロー

プローブは安価で冪等であり手操作と並行可能に。ハウスキーピングはログローテーションやキャッシュ整理に限定し、ユーザー可変状態と共有しない。業務フロー（日報やチャンネル要約）はオーナー、再試行上限、冪等キーを必須化し二重発火でのスパムを防ぐ。

バックプレッシャーと外部 API

外部 API 呼び出しには指数バックオフとジッターを載せ、ジョブ名別に HTTP ステータス分布を記録して 429 の増加を早期検知する。モデルプロバイダでは対話トラフィックとバッチ要約を分離しトークン予算に整合させる。

SLO と「成功ログ欠如」アラート

「UTC で日次ダイジェストは予定時刻+15 分以内」などの SLO を定義し、成功ログが来ないこともアラート対象にする。ディスク圧や OAuth 失効と相関が取りやすい。

自動ジョブのセキュリティ境界

管理者 CLI トークンと分離した最小権限、チャンネル権限の狭義化、昇格前の同一ボリュームバックアップを徹底する。破壊的操作は人手承認経路へ。

systemd タイマからの移行

しばらく半頻度で新ジョブを走らせ旧タイマの指標と突き合わせ、二週間一致後に旧経路を止める。同一 SQLite/JSON をファイルロックなしで二重書きしない。

観測性：1 回の発火をミニトランザクションとして追跡

enqueue・ピックアップ・チャネル送信・モデル呼び出し・永続化までを run_id で貫通させ、再試行でも相関を失わないようにします。キュー深度と最古待ち時間を併記し、CPU が平坦なのに詰まる場合は外部 API かロックを疑います。

時計ずれとスリープによる取りこぼし

ノート PC の睡眠や VM スナップショット停止は分境界のジョブを落とします。権威あるスケジューラは常時稼働かつ睡眠に強いホストへ寄せ、取りこぼし許容なら補走ポリシーを文書化します。NTP 健全性を週次チェックに含めます。

リースとメンテ窓

共有開発機では再起動が交渉事になりがちです。Gateway と cron を専用リモート Mac に分離するとメンテ計画と証明書期限管理が単純化します。MACCOME の六国リージョン独占ノードは変動要因を減らすための「退屈な」基盤です。

Runbook に書く項目

影響範囲、ロールバック手順、依存サービス、ドライラン可否を四半期ごとに更新し、陳腐化した手順書からくる静かな劣化を防ぎます。