Summary
Manual cron job execution via openclaw cron run <jobId> enqueues successfully but the embedded runner never starts the LLM call. Job is marked as "running" (runningAtMs set) but produces zero activity until it times out after 1200s.
Scheduled automatic execution works fine. Only manual triggers are broken.
Environment
- OS: Linux 6.8.0-100-generic (x64)
- Node: v22.22.0
- OpenClaw: 2026.3.8 (3caab92)
- Gateway: local loopback 127.0.0.1:18789
Steps to reproduce
- Have a working cron job (ours ran successfully on schedule at 12:15 UTC today)
- Run
openclaw cron run <jobId>
- CLI returns
{ enqueued: true, runId: "manual:..." }
runningAtMs is set in jobs.json
- Zero LLM/agent/cron activity in gateway logs
- Job sits "running" until timeout (1200s) with
lane wait exceeded: lane=cron
What works ✅
- Scheduled automatic cron execution (ran fine at 12:15 UTC)
cron add, list, status, remove, runs, edit
- Simple one-shot
--at crons (first run after gateway restart)
- Sub-agent spawns from main session
What fails ❌
openclaw cron run <jobId> — tested 8+ times across multiple gateway restarts
- Tested with both
opus and sonnet models
- Tested with
isolated and main session targets
- Tested with
delivery.mode: "none" and delivery.mode: "announce"
- Tested with fresh sessions (purged all 78 cron session mappings from sessions.json)
Log behavior
# Enqueue succeeds
{ "enqueued": true, "runId": "manual:36f76eaf-...:1773069058800:1" }
# Gateway logs show NOTHING cron-related after enqueue
# Only inbound/outbound WhatsApp from other sessions
# No LLM call, no tool invocation, no error
# Eventually times out:
lane wait exceeded: lane=cron waitedMs=1199897 queueAhead=0
FailoverError: LLM request timed out
Key observations
- A simple one-shot
--at cron that just sends a WhatsApp message worked immediately after a gateway restart
- The next manual
cron run on a different job (same restart) did not work
- This suggests the manual trigger path has a different code path than scheduled execution
openclaw status shows the cron session exists with 46k tokens cached, but no new activity
Possibly related
Workaround
None found. Scheduled execution works, so time-critical crons can be scheduled with --at as a workaround, but cron run for ad-hoc testing is broken.
Summary
Manual cron job execution via
openclaw cron run <jobId>enqueues successfully but the embedded runner never starts the LLM call. Job is marked as "running" (runningAtMsset) but produces zero activity until it times out after 1200s.Scheduled automatic execution works fine. Only manual triggers are broken.
Environment
Steps to reproduce
openclaw cron run <jobId>{ enqueued: true, runId: "manual:..." }runningAtMsis set injobs.jsonlane wait exceeded: lane=cronWhat works ✅
cron add,list,status,remove,runs,edit--atcrons (first run after gateway restart)What fails ❌
openclaw cron run <jobId>— tested 8+ times across multiple gateway restartsopusandsonnetmodelsisolatedandmainsession targetsdelivery.mode: "none"anddelivery.mode: "announce"Log behavior
Key observations
--atcron that just sends a WhatsApp message worked immediately after a gateway restartcron runon a different job (same restart) did not workopenclaw statusshows the cron session exists with 46k tokens cached, but no new activityPossibly related
Workaround
None found. Scheduled execution works, so time-critical crons can be scheduled with
--atas a workaround, butcron runfor ad-hoc testing is broken.