OpenClaw Fixes Silent and Misrouted Global Cron Failure Alerts
A main-branch fix restores global webhook and chat failure destinations while preventing duplicate or cross-channel notifications. Operators should test forced failures after upgrade.
OpenClaw has fixed a failure-alert routing bug that could make globally configured cron alerts disappear, go to a failed job’s unrelated chat channel, or duplicate a job-owned failure notification.
For operators, this is monitoring integrity: a scheduled task can fail correctly while its alerting layer lies about where—or whether—the failure was reported. The fix is merged to main, so verify the containing release before assuming an installed system has it.
Who should investigate
- operators using global
cron.failureAlert.toorcron.failureAlert.channeldestinations; - deployments where scheduled jobs deliver ordinary output to a different channel from the incident destination;
- jobs with explicit channel-shaped or webhook
delivery.failureDestinationsettings; and - teams relying on
includeSkippedalerts or clear-only destination objects as an opt-out.
A successful cron run does not test this path. Acceptance needs controlled failures and destination-level evidence.
What was broken
The canonical thresholded failure-alert path ignored the existing global destination fields. According to PR #113737, a global webhook could receive nothing, while a global Slack alert could be inherited into the failed job’s Telegram channel.
A first correction exposed another regression: when a failed job already owned a channel or webhook failure destination, the inherited global alert could be dispatched as well. That produced two notifications for one failure and risked crossing destination boundaries.
The final merged logic resolves global destinations in the existing failure-alert owner, then suppresses inherited global delivery for an error only when the job already owns its completion failure destination.
What remains intentionally distinct
The fix does not flatten every notification into one global route. The merged contract preserves:
- explicit per-job failure alerts;
- threshold and cooldown behavior;
- best-effort delivery and account selection;
- compatible channel inheritance;
- clear-only destination objects as an opt-out; and
- opted-in skipped-job alerts, even when the job has a failure destination.
That last distinction is important. A skipped run and an errored run are different operational signals; duplicate suppression for errors must not silently erase requested skipped-run notifications.
No configuration schema, Gateway protocol or SQLite migration accompanies this change. Operators do not need to rewrite valid alert configuration merely because the routing owner was corrected.
A practical acceptance matrix
After moving to a build that explicitly contains landed commit 1e93e78e, create disposable jobs and verify at least these cases:
| Test | Expected result |
|---|---|
| Global webhook, job has no explicit failure destination | One failure alert reaches the configured webhook; no unrelated channel receives it. |
| Global chat destination differs from the job’s ordinary delivery channel | One alert reaches the configured global chat target, not the job’s normal destination. |
| Job has an explicit channel failure destination | Exactly one alert reaches that channel; the inherited global destination does not also fire. |
| Job has an explicit webhook failure destination | Exactly one webhook notification is received. |
| Job has a clear-only destination object | No inherited global error alert is delivered. |
includeSkipped is enabled |
A deliberately skipped job still produces the configured skipped alert. |
Use synthetic payloads and non-production destinations. Record notification IDs, timestamps and destination identity without logging webhook secrets. Clean up the disposable jobs after the matrix passes.
Evidence and limits
The merged pull request reports real reproductions of the silent global-webhook case and Slack-to-Telegram misrouting. Its final evidence reports 292 passing tests across Gateway, RPC and cron suites, including the regression tied to issue #102235, plus 123 successful exact-head checks.
Those are upstream results. OpenClaw Academy verified the official merged record and landed commit but did not force failures against a live multi-channel installation.
Bottom line
Cron without trustworthy failure delivery is just delayed surprise. If global alerts protect scheduled work, treat the containing release as a monitored upgrade: force one failure per ownership path, confirm exactly one notification reaches the intended destination, and prove that opt-outs plus skipped-run alerts still behave as configured.
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