OpenClaw

OpenClaw cron not running: scheduled jobs never fire

Last checked

The error

[cron] cron: worker refresh delayed {"err":"SqliteWorkerError: Shared-state worker lease is closed"}

cron: scheduler disabled; jobs will not run automatically

Usually there is no error at all: the job shows as enabled and its time just passes. These are the two Gateway log lines worth searching for with openclaw logs --follow. The first is the 2026.10.x scheduler bug, the second means scheduling is switched off.

OpenClaw's scheduler runs inside the Gateway, so a job only fires when that Gateway is running, scheduling is enabled and the job has a next run time. Run openclaw cron status and openclaw cron list --all. If status says enabled: true but nextWakeAtMs is in the past and the log shows "Shared-state worker lease is closed", the scheduler worker died: restart the Gateway. Otherwise check cron.enabled, OPENCLAW_SKIP_CRON, disabled jobs and the job's --tz.

Why it happens

Automations (OpenClaw's name for cron jobs; openclaw cron and openclaw automations are the same command) are stored in the SQLite state database and fired by the running Gateway, not by the CLI you created them from. A manual run bypasses the schedule, so "openclaw cron run works but the schedule does not" points at the scheduler, the Gateway or the job's timing, not the job itself.

  1. The scheduler worker stopped on 2026.10.x. The scheduler's timer lives in a shared SQLite worker. If that worker is retired while the Gateway keeps running, every refresh logs "cron: worker refresh delayed" with "Shared-state worker lease is closed", cron status still reports enabled: true with a nextWakeAtMs in the past, and nothing fires until a restart. Manual runs still start (issue #194032, reported on 2026.10.10).
  2. Scheduling is switched off, or the job is. cron.enabled: false in openclaw.json or OPENCLAW_SKIP_CRON=1 in the Gateway's launch environment stops automatic runs but not manual ones. Jobs can also be auto-disabled after terminal failures, or paused when the conversation that created them was removed or archived.
  3. The schedule means something other than you think. Cron expressions without --tz use the Gateway host's timezone, and --at times without an offset are UTC. When both day-of-month and day-of-week are set, croner fires when either matches, so 0 9 15 * 1 runs on every 15th and every Monday. Top-of-hour expressions are staggered by up to 5 minutes unless you use --exact.
  4. The Gateway was not running, or a different one is. Automation commands need a running Gateway. Leftover launchd, systemd or schtasks services from older installs can leave a second gateway, and on macOS launchd can stop restarting a Gateway after a crash burst until you log in or open the dashboard.
  5. An upgrade left state behind. "Default cron partition selection is unresolved" means cron is waiting for you to pick a partition in openclaw doctor --fix. Jobs still in the old jobs.json and jobs-state.json files are not read by current releases: install 2026.9.7, run its Doctor, then upgrade.

The fix

  1. 1 Run openclaw cron status and openclaw cron list --all. Note whether scheduling is enabled, whether your job is enabled, and when it is next due.
  2. 2 If nextWakeAtMs is in the past, search openclaw logs --follow for "Shared-state worker lease is closed". If it is there, run openclaw gateway restart to bring the scheduler back. The recovery fix (PR #194048) merged to main on 12 November 2026 and is not in a release yet; 2026.11.3 still has the bug.
  3. 3 If the log says the scheduler is disabled, remove cron.enabled: false from openclaw.json and OPENCLAW_SKIP_CRON from the Gateway's environment (service unit, launchd plist or container env), then restart the Gateway.
  4. 4 If the job is disabled, run openclaw doctor to see the recorded auto-disable reason, fix that cause, then run openclaw cron enable <jobId>.
  5. 5 Check the timing with openclaw cron show <jobId>. Set the timezone explicitly, for example openclaw cron edit <jobId> --cron "0 7 * * *" --tz Europe/London, and add --exact if the minute matters. For "the 15th, only if it is a Monday" use 0 9 15 * +1.
  6. 6 Test the job itself with openclaw cron run <jobId> --wait. It force-runs by default and exits 0 only if the run succeeded. If it works, the job is fine and the problem is the scheduler or timing. If it fails, read openclaw cron runs <jobId> --limit 20.
  7. 7 Run openclaw gateway status --deep to catch a second or stale gateway service. After an upgrade, run openclaw doctor --fix interactively: --yes leaves the cron partition choice unresolved.
openclaw cron status

Commands from older guides

Older posts tell you to run openclaw cron run --id <jobId> --force and to edit ~/.openclaw/cron/jobs.json. Current docs take the job id as a plain argument, and openclaw cron run already force-runs, so no extra flag is needed.

Jobs, pending state and run history moved into the SQLite state database in 2026.6.1. Editing JSON files does nothing now: change schedules with openclaw cron add, edit and remove.

openclaw cron run <jobId> --wait
openclaw cron runs <jobId> --limit 20

Use openclaw cron run <jobId> --due instead to check whether the job is actually due. It honours the job's condition gate and does not make the job due early.

Still failing?

  • The job ran but nothing arrived in chat. That is delivery, not scheduling: openclaw cron show <jobId> previews the resolved route and the last delivery status.
  • Runs show as skipped for a local model. The scheduler checks that an Ollama or other local endpoint is reachable before the turn and skips the run if it is not. Start the model server.
  • The Gateway itself keeps dying. Check memory first: the shared SQLite worker has a 512 MB heap cap, and the database admission page below covers the same worker running out of memory.

Related errors

Full guideHow to Schedule an AI Agent to Run Automatically (No Code Required)Every error, one page10 Common OpenClaw Errors in 2026 and How to Fix Each One

Hit a different error?

Paste any agent error and get the cause and fix in seconds.

Open the decoder

Frequently asked questions

Why does openclaw cron run work but the schedule never fires?

A manual run skips the schedule and executes the job straight away, so the job is fine. The problem is the scheduler, scheduling being disabled, or the job's timing. Check openclaw cron status, then the Gateway log for "Shared-state worker lease is closed".

What does nextWakeAtMs in the past mean?

The scheduler stopped waking up at the time it planned. On 2026.10.x the usual reason is the scheduler worker being lost while the Gateway keeps running (issue #194032). Restarting the Gateway recovers it until a release ships the fix.

Which timezone does an OpenClaw cron job use?

The Gateway host's timezone, unless you set --tz with an IANA name such as Europe/London. A one-shot --at time without an offset is treated as UTC.

Is openclaw cron the same as openclaw automations?

Yes. They are two names for the same command, and every subcommand works with either spelling.

Do missed jobs run when the Gateway comes back?

By default yes: missed recurring slots are caught up, though jobs that need an agent are rescheduled rather than replayed at the moment of startup. Set cron.skipMissedJobs: true to skip missed recurring slots instead.

Stop firefighting agent errors

Decoding errors one at a time is the manual version of what BetterClaw automates. Run your agents on a no-code AI agent platform with managed models, retries and config validation built in.

Deploy Your Agent — Start FreeBook a Demo

Free plan available · Pro $49/mo · BYOK · 7-day free trial