OpenClaw Main Fixes Silent Cron Webhooks and Missed Restart Slots
Merged cron fixes restore primary webhook delivery records, replay subsecond restart misses, preserve failure-alert account ownership and link tasks to the right transcript.
OpenClaw has merged four cron corrections covering whether a scheduled run fires, whether its primary webhook is actually delivered, where failure alerts go and which transcript an active task opens.
The most serious upstream reproduction is blunt: a command job configured with --webhook fired twice, completed successfully, produced payloads, delivered nothing and recorded deliveryStatus: "unknown". That is not a failed job; it is a successful execution wrapped in a lying delivery record.
All four fixes are on main. Operators should identify a containing release or revision and run a controlled acceptance matrix before relying on the new behavior.
Primary webhook delivery is now part of the run outcome
PR #117783 repairs the path where a cron command’s primary webhook could be skipped while run history remained ambiguous. The merged behavior delivers the payload and records the accepted webhook outcome rather than leaving delivery at unknown.
This is distinct from failure-alert routing. A primary webhook is the requested destination for normal job output; a failure destination reports that execution or delivery failed. Monitoring must keep those roles separate.
After upgrade, a run marked successful should have an explainable delivery state. “Unknown” must trigger investigation, not be treated as a harmless synonym for accepted.
Restarts no longer lose a slot less than one second old
PR #117797 fixes restart catch-up when a missed cron slot began less than one second before Gateway restart. The recovery boundary excluded that near-current slot, allowing the automation to disappear without a run record.
The correction uses the existing inclusive previous-slot logic. Operators with frequent deployments or supervised restarts should specifically test the subsecond edge; ordinary minute-away schedules will not exercise it.
Failure alerts keep valid route and account ownership
PR #117765 fixes two routing cases: a valid failure destination on another channel could be rejected by Gateway validation, and an alert explicitly targeting the main recipient could lose account or thread ownership.
This follows earlier global failure-alert repairs but is a distinct destination-identity problem. A notification reaching the correct platform through the wrong account or thread is still misdelivery.
Active tasks open the execution transcript
PR #117679 fixes task links that could point to the session which created the job rather than the transcript where the scheduled run was executing. During an incident, that sends an operator to unrelated context or to a provisional key that never received the run.
The fix does not change execution itself, but it changes whether evidence is findable when a task is live.
Acceptance matrix
Use disposable jobs and synthetic payloads:
| Test | Expected result |
|---|---|
| Successful command with primary webhook | One request arrives; run history records a non-unknown accepted outcome |
| Webhook rejects or times out | History distinguishes failure from accepted delivery; no invented success |
| Gateway restarts just after a due slot | One catch-up run appears, not zero or two |
| Failure alert targets another valid channel | Gateway accepts the route and sends one alert there |
| Alert uses a specific account and thread | Provider evidence matches both identities |
| Open an active task | Link resolves to that run’s execution transcript |
Give each payload a unique run key and make the receiver deduplicate. Restart-boundary tests can produce late or repeated requests if the old deployment has additional faults.
Incident response for older builds
If webhook-backed jobs previously showed status: ok with deliveryStatus: unknown:
- compare run payload creation with receiver logs;
- do not infer delivery from execution success;
- reconcile each run key before replay;
- inspect restart timestamps for schedules due within the boundary; and
- preserve account, channel and thread identity for any failure alert.
Interpretation: scheduled automation has separate execution, delivery and observability outcomes. A truthful system records each one instead of compressing them into a single green status.
Evidence and limits
The official merged GitHub records supplied by the repository collector establish the production-host webhook reproduction and the landed corrections. Direct PR extraction was blocked by GitHub HTTP 403. OpenClaw Academy did not invoke a live webhook or restart a production Gateway, and PR #117783 remained labelled as needing more proof in the collected record. Treat staging evidence as mandatory.
Bottom line
Cron operators should not accept “the job ran” as proof that anyone received its output. Test a containing build across primary delivery, restart catch-up, failure routing and transcript linkage, then alert whenever execution and delivery state disagree.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF