2026 OpenClaw Cron und unbeaufsichtigter Gateway-Betrieb: Zeitzonen und Fehlerrecovery (dedizierter Remote-Mac)

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.

Job-Taxonomie: Sonden, Housekeeping, Business-Flows

Sonden müssen billig und idempotent sein. Housekeeping rotiert Logs und räumt Caches, ohne Nutzerzustand zu teilen. Business-Flows brauchen Owner, Retry-Budgets und Idempotenzschlüssel.

Backpressure und externe APIs

Exponentielles Backoff mit Jitter, HTTP-Statusverteilung pro Jobname loggen, 429-Drift früh erkennen. Modell-Traffic trennen.

SLOs und fehlende Erfolgslogs

Definieren Sie z. B. Fertigstellung innerhalb von 15 Minuten nach UTC-Trigger; alarmieren Sie auch auf ausbleibende Erfolgslogs.

Sicherheitsgrenzen

Mindestprivileg getrennt von Admin-CLI, enge Channel-Scopes, Backups vor Upgrades. Destruktives nur mit Freigabe.

Migration von systemd-Timern

Halbfrequente Doppelspur, Metrikvergleich über zwei Wochen, dann Abschaltung. Kein doppeltes Schreiben ohne Lock.

Observability: jede Ausführung als Mini-Transaktion

Verketten Sie Enqueue, Pickup, Kanalversand, Modellaufruf und Persistenz mit stabilen run_id-Feldern. Messen Sie Warteschlangentiefe und älteste Wartezeit; bleibt die CPU flach bei wachsender Tiefe, liegt das Problem selten an der Inferenz, sondern an APIs oder Locks.

Uhr, Sleep und verpasste Trigger

Notebooks im Sleep und pausierte VMs verpassen Minutengrenzen. Verlegen Sie autoritative Scheduler auf dauerhaft wache Hosts und dokumentieren Sie Nachhollogik statt stiller Doppelfeuer. NTP-Health wöchentlich prüfen.

Leasing und Wartungsfenster

Geteilte Entwicklerhardware macht jeden Neustart zum Koordinationsproblem. Dedizierte Remote-Macs vereinfachen Freeze-Fenster und Snapshots vor Major-Upgrades. MACCOME-Regionen bieten bewusst langweilige, single-tenant Silizium-Kapazität.

Runbook-Pflichtfelder

Blast Radius, Rollback, Abhängigkeiten und Dry-Run-Flags vierteljährlich prüfen, damit veraltete Playbooks keine stillen Regressionen nähren.