solution gateway high macos linux windows

Cron: jobs don't fire and nextRunAtMs silently advances

Fix cron jobs that skip runs (no execution/logs) while nextRunAtMs advances by upgrading past known scheduler regressions and verifying cron storage + timezone.

By CoClaw Team Updated March 13, 2026

Symptoms

  • A cron job looks enabled and has a valid nextRunAtMs, but it never executes.
  • At the scheduled time:
    • no logs appear for the run,
    • openclaw cron runs --id <job-id> stays empty,
    • and nextRunAtMs advances to the next occurrence anyway (as if it ran).
  • Variant: cron jobs fire on gateway start (startup catch-up), then stop firing entirely until the next service restart.

Cause

This is usually caused by a Gateway cron scheduler regression in some OpenClaw versions where maintenance logic can advance a past-due nextRunAtMs without executing the run.

It can also be caused by mismatched assumptions around timezones (host timezone vs explicit tz).

Fix

1) Upgrade OpenClaw and restart the gateway

Upgrade to the latest OpenClaw (or at least a version that includes the cron scheduler fixes), then restart:

openclaw --version

# npm global install
npm update -g openclaw

openclaw gateway restart

2) Verify cron storage + job state

List jobs and confirm the scheduler sees it as enabled with a future nextRunAtMs:

openclaw cron list
openclaw cron runs --id <job-id>

If the job is supposed to run at a specific wall-clock time, set an explicit timezone:

openclaw cron edit <job-id> --tz "America/Los_Angeles"

3) If you need reliability right now, use an external scheduler as a stopgap

If you are hitting the “runs only at startup catch-up” variant, treat it as a scheduler stall until proven otherwise.

Operational fallback options:

  • systemd timer / Task Scheduler calls openclaw cron run <job-id> on your desired cadence, or
  • move the critical work to heartbeat (main session) so it runs on a known interval.

Verify

  • Wait for the next scheduled time and confirm the job appears in:
    • openclaw cron runs --id <job-id>
  • If it is a main-session job, confirm the system event is delivered.
  • If it is an isolated job, confirm it produces an isolated run and (if enabled) delivery happens.

Verification & references

  • Reviewed by:CoClaw Code Team
  • Last reviewed:March 14, 2026
  • Verified on: macOS · Linux · Windows
Want to explore more? Browse all solutions or ask in the Community Forum .
Report a problem

Related Resources

Cron: jobs run but Telegram announce delivery fails (no notification sent)
Fix
If isolated cron jobs execute successfully but the Telegram notification never arrives ("cron announce delivery failed"), disable announce and send via the message tool, or switch delivery mode while you capture gateway logs for the failing announce path.
Cron: isolated jobs fail with 'Field required' on tools.function
Fix
Work around isolated cron job failures that reject tool definitions with `Field required` on `tools.function` by temporarily switching the job to the main-session systemEvent path.
Cron: announce delivery sends a summary instead of the full output (Telegram topics / chat channels)
Fix
If an isolated cron job used to deliver the full output but now sends a summary (or leaks extra text like thinking/reasoning), disable announce delivery and send a clean final message explicitly.
OpenClaw Cron & Heartbeat: Make Your Agent Actually Run 24/7
Guide
Build a reliable OpenClaw cron and heartbeat baseline: keep the gateway truly always-on, prove runs really executed, design delivery that leaves evidence, and verify automation survives restarts and upgrades.
OpenClaw on Native Windows: A Gateway Stability Playbook for SecretRefs, RPC Timeouts, and Cron Drift
Guide
A practical Windows operator guide for keeping OpenClaw stable when CLI SecretRef warnings disagree with gateway health, RPC probes time out under load, and cron jobs need a safer baseline.
OpenClaw TASKS.md Template: A Simple Workspace Task Board
Guide
Download a ready-made TASKS.md file for your OpenClaw workspace to track multi-step work, make cron runs leave evidence, and reduce 'it promised but I can't see what happened' failures.