Summary

On 2026.6.5 (5181e4f), per-job failure alerts configured with failureAlert.after = 1 never fire. Every errored cron run ends with delivery_status: "not-requested" in cron_run_logs, and every job's state shows lastFailureNotificationDeliveryStatus: "not-requested" — no notification is ever requested, let alone delivered.

Environment

• OpenClaw 2026.6.5 (5181e4f), macOS (darwin), gateway under launchd
• This install went through the 2026.6.5 legacy-JSON → SQLite cron-store migration (and separately hit the frozen-scheduler state after upgrade, cleared via doctor --fix + restart)

Evidence (one day, 2026-06-10)

7 errored runs across 3 jobs, all of which have failureAlert.after = 1 with a messaging channel target configured:

Zero alerts were delivered for any of them. In SQLite:

select status, delivery_status, count(*) from cron_run_logs
where status='error' and ts > (strftime('%s','now')-86400)*1000
group by 1,2;
-- error | not-requested | 6   (plus one earlier row with delivery_status = 'unknown')

All affected jobs' persisted state shows lastFailureNotificationDeliveryStatus: "not-requested".

Expected

An errored run on a job with failureAlert.after = 1 should request and deliver a failure notification to the configured channel after the first consecutive failure.

Notes / possibly related

• [Bug]: failureAlert silently drops when cron stalls in runtime-plugins phase — lastFailureNotificationDeliveryStatus="unknown", operator never sees the failure #89847 covers failureAlert being dropped when a run stalls in the runtime-plugins phase with status "unknown" — but here even ordinary execution-timeout errors never request delivery, which looks broader.
• Migration context may be relevant: v2026.6.5: Cron doctor preflight overwrites API-updated schedules with stale legacy JSON data #91944 / Cron run-history not persisted after 2026.6.x upgrade — runs/history.db + runs/index.db remain 0-byte; legacy runs/*.jsonl migrated to .migrated #91917. One hypothesis is that the cron-store SQLite migration didn't carry the failure-alert request path into the new runtime, since delivery_status stays at its initial not-requested value for every run, ok or errored.

Repro

1. On 2026.6.5, configure any cron job with failureAlert.after = 1 and a channel target.
2. Force the run to error (e.g. a payload that exceeds timeoutSeconds).
3. Observe: no notification; cron_run_logs.delivery_status = 'not-requested'.

🤖 Generated with Claude Code