Summary
When a cron job is added, modified, or deleted, OpenClaw should fire an internal event (or invoke a configurable webhook/callback) so external tooling can react immediately.
Problem
Currently there is no trigger-on-change mechanism for the cron subsystem. If jobs.json is wiped (e.g. by a gateway restart with fewer jobs in memory), a daily scheduled backup can be up to 24 hours stale.
Tonight we experienced exactly this: jobs.json went from ~86 jobs to 5 jobs after a gateway restart mid-session. Because the last backup was from Mar 12, we lost ~66 job configs created in the interim.
Proposed Solution
Add a cron.onChange event fired whenever a job is created, updated, or deleted. It should be consumable in at least one of these ways:
- Webhook/callback URL — POST a payload to a configurable URL on each change
- System event injection — fire a
systemEvent into a named session (e.g. main) with the change type and job ID
- File write hook — execute a shell command / script path on change
Minimum viable event payload:
{
"event": "cron.change",
"action": "created" | "updated" | "deleted",
"jobId": "uuid",
"jobName": "job name",
"timestamp": "ISO-8601"
}
Use Case
We use a "Cron Registry" skill (Nancy, our librarian agent) that snapshots jobs.json to markdown + JSON + external drive. Today it runs daily at 7 AM. With a trigger-on-change hook, the registry would always be current regardless of when a wipe occurs.
Workaround Today
Dear daily 7 AM snapshot + a tripwire alert if jobs.json has fewer than 10 jobs. This helps but leaves a gap.
Priority
Medium. Workaround exists but data loss from a wipe is a real operational risk for anyone with many active jobs.
Summary
When a cron job is added, modified, or deleted, OpenClaw should fire an internal event (or invoke a configurable webhook/callback) so external tooling can react immediately.
Problem
Currently there is no trigger-on-change mechanism for the cron subsystem. If
jobs.jsonis wiped (e.g. by a gateway restart with fewer jobs in memory), a daily scheduled backup can be up to 24 hours stale.Tonight we experienced exactly this:
jobs.jsonwent from ~86 jobs to 5 jobs after a gateway restart mid-session. Because the last backup was from Mar 12, we lost ~66 job configs created in the interim.Proposed Solution
Add a
cron.onChangeevent fired whenever a job is created, updated, or deleted. It should be consumable in at least one of these ways:systemEventinto a named session (e.g.main) with the change type and job IDMinimum viable event payload:
{ "event": "cron.change", "action": "created" | "updated" | "deleted", "jobId": "uuid", "jobName": "job name", "timestamp": "ISO-8601" }Use Case
We use a "Cron Registry" skill (Nancy, our librarian agent) that snapshots
jobs.jsonto markdown + JSON + external drive. Today it runs daily at 7 AM. With a trigger-on-change hook, the registry would always be current regardless of when a wipe occurs.Workaround Today
Dear daily 7 AM snapshot + a tripwire alert if
jobs.jsonhas fewer than 10 jobs. This helps but leaves a gap.Priority
Medium. Workaround exists but data loss from a wipe is a real operational risk for anyone with many active jobs.