Cron timezone | Friends of the Crustacean 🦞🤝 | Page 1

copper hare Apr 23, 2026, 6:37 PM

#

It looks like the cron jobs are fired at wrong timezone.

For example

    "expr": "0 8 * * *",
    "tz": "Europe/Brussels"

fires at 10

crisp briarBOT Apr 23, 2026, 6:37 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

versed jayBOT Apr 23, 2026, 6:42 PM

#

Let me check the docs and the cron code path so I can give you something concrete, not a guess.

#

I found the cron docs and source, and cron is supposed to honor schedule.tz. I’m checking whether this is a real scheduler bug or a display mismatch in the UI/logs.

#

This looks a lot like the schedule is getting treated as UTC instead of Brussels time. I’m doing one quick repro against the cron library path so I don’t hand-wave it.

#

That’s not expected.

I checked the current docs/source, and cron should honor schedule.tz.
0 8 * * * with Europe/Brussels should resolve to 08:00 Brussels, not 10:00.

Can you paste these?

openclaw --version
openclaw cron show <job-id> --json
openclaw cron runs --id <job-id> --limit 5 --json

A couple likely causes:

you’re on an older version with a cron bug
the job has a stale persisted nextRunAtMs

#

the cron store is in a legacy shape

If you edited the cron JSON by hand, I’d especially suspect stale runtime state. Re-saving via CLI should force a recompute:

openclaw cron edit <job-id> --cron "0 8 * * *" --tz "Europe/Brussels"
openclaw doctor --fix

Docs:

If you paste the show --json output, I can narrow it down pretty quickly.

copper hare Apr 23, 2026, 7:07 PM

#

openclaw --version
OpenClaw 2026.4.15 (041266a)
openclaw cron show d4e66f03 --json
error: unknown command 'show'

versed jayBOT Apr 23, 2026, 7:08 PM

#

Yep, show is newer, it is not in 2026.4.15. Use list on that version.

Also, a jump from 8 → 10 is not the normal cron stagger. That looks like the job was effectively scheduled as 08:00 UTC instead of 08:00 Europe/Brussels.

Most likely cause: the job was edited by hand in the cron JSON, so the stored nextRunAtMs stayed stale.

A few things:

0 8 * * * in Brussels should be 08:00 local
top-of-hour cron does have an automatic stagger, but only up to 5 minutes, not 2 hours

Can you try this?

openclaw cron edit d4e66f03 --cron "0 8 * * *" --tz "Europe/Brussels" --exact
openclaw cron list --json

#

openclaw cron runs --id d4e66f03 --limit 5 --json

If you did edit jobs.json manually, that’s probably the bug. Re-saving the job via CLI should recompute it properly.

If it still looks wrong after that:

openclaw doctor --fix
openclaw gateway restart

Also, did you create/edit this via CLI/UI, or by editing the JSON store directly? That detail matters a lot here.

Docs:

https://docs.openclaw.ai/cli/cron

#Cron timezone