Cron vs. Heartbeat Scheduling Gotcha (This Instance)¶
Notes¶
Summary¶
Summary¶
On this OpenClaw instance, cron jobs that target the main session with a systemEvent payload do not reliably fire — the job reports status: ok on manual force-runs but completes in 7-14ms, far too fast to have actually executed a real turn (checked calendar/email, called gog, composed a reply). It logs the trigger as dispatched without the main session actually processing it.
Working substitute: heartbeat polling. Heartbeat runs with the full session's tool access (Bash, gog, etc.), unlike cron's agentTurn payloads, which are restricted from shell access. HEARTBEAT.md can carry a time-window check (e.g. "if between 8:00-8:35 AM and not already sent today, do X") that heartbeat polls against on its normal interval.
Tradeoff¶
Heartbeat-based scheduling lands somewhere inside the poll window (default ~30 min), not at an exact time. That's the cost of using the mechanism that actually has tool access, versus a cron trigger that would be exact but silently doesn't fire for main+systemEvent targets.
When this applies¶
Any time a scheduled/automated task needs real tool access (shell, MCP tools, gog, etc.) and is being routed through cron targeting the main session — check whether it's actually running a real turn (timing/output evidence) before trusting a green status: ok.