Summary

After migrating OpenClaw cron config from a single daily Instagram editorial job to split weekday/weekend jobs, the old daily schedule appears to have remained active in memory. On Saturday, April 25, 2026, the old daily job fired at 06:00 America/Sao_Paulo and the new weekend job fired at 07:00, causing two Telegram deliveries for the same editorial flow.

What I expected

Only the weekend job should have run on Saturday.

What happened

Two distinct cron jobs delivered to the same Telegram target on the same Saturday morning:

• weekday job e246053c-2041-49b1-8d71-a00d75730503 ran at 2026-04-25 06:00:00 -03
• weekend job 4cc17c47-c6a4-4a3d-a091-2bcf1cd55314 ran at 2026-04-25 07:00:00 -03

Deliveries arrived at:

• 06:34:16 -03
• 07:03:25 -03

This caused two Telegram messages for what should have been a single daily editorial delivery.

Current config

Current /home/gulp-digital/.openclaw/cron/jobs.json shows:

• weekday job e246053c-2041-49b1-8d71-a00d75730503
  • 30 5 * * 1-5
• weekend job 4cc17c47-c6a4-4a3d-a091-2bcf1cd55314
  • 30 6 * * 0,6

So the weekday job should not have fired on Saturday.

Historical evidence

I found older backups of the cron store:

jobs.json.bak

Shows the same main job id e246053c-2041-49b1-8d71-a00d75730503 previously configured as:

• 0 1 * * *

and a retry job at:

• 0 7 * * *

jobs.json.bak-2026-04-22-0912

Shows a later intermediate state where the same main job id e246053c-2041-49b1-8d71-a00d75730503 was configured as:

• 0 6 * * *

At that point there was still no separate weekend job.

Why this looks like stale in-memory cron state

The observed Saturday run at 06:00 matches the older daily 06:00 schedule, not the current weekday-only schedule.

That suggests the gateway process that was alive overnight still had an older schedule loaded in memory, while the persisted cron store later reflected the newer split weekday/weekend config.

In other words, this does not look like cron parsing 1-5 incorrectly as including Saturday. It looks more like one of these:

1. cron schedule mutation did not invalidate already loaded timers
2. gateway needed an explicit reload/restart after editing cron jobs
3. cron store update and active in-memory schedule diverged temporarily

Extra details

• jobs.json mtime after the morning runs was 2026-04-25 07:03:25 -03
• the gateway process currently running started only later at 2026-04-25 10:01:13 -03, so it was not the process that scheduled the 06:00 and 07:00 runs
• I did not find evidence of a restart between 05:00 and 08:30, which further weakens the idea of a fresh cron parser bug and strengthens the stale loaded schedule hypothesis

Impact

This can produce duplicate external deliveries when a cron schedule is changed from one pattern to another but the old timer remains active.

Request

Please check whether cron job edits properly invalidate and reschedule in-memory timers, especially when:

• an existing job id changes its cron expression
• one daily job is split into weekday + weekend jobs
• the gateway keeps running across that migration

It would also help if cron startup / reschedule logs included the effective loaded expression per job, so this kind of issue can be diagnosed more directly.