OpenClaw merged a P1 cron reliability fix tonight in PR #133552, titled fix(cron): keep read RPCs from blocking the gateway. The change targets a subtle but expensive scheduler behavior: ordinary cron reads could trigger synchronous SQLite write maintenance after the scheduler had already started.
That meant calls intended to inspect cron state, plus timer ticks that had no runnable job, could still enter maintenance paths. On larger stores, those no-op or read-like operations could block the Gateway event loop long enough to be visible to operators.
What Changed
OpenClaw now keeps started cron reads observational. Cron status, list, paginated list, and individual job-read calls load the current state without repairing durable schedule rows once the scheduler is running.
The exception is intentionally narrow. Reads before scheduler startup can still perform the existing missing-schedule repair, because there is no running scheduler watchdog to clean up that state yet.
Timer maintenance was narrowed too. Empty timer ticks enter maintenance only when there is an exact expired repair candidate or an enabled timed job with no valid next run and no active marker. Stable future jobs, event-driven jobs without a next run, and active queued or running work no longer trigger no-op sweeps.
Why Gateway Operators Should Care
The practical effect is simple: looking at cron state should not make the Gateway do heavy write work. That matters for dashboards, health checks, automation monitors, and agents that call cron read tools frequently.
The PR notes that the bug was introduced by commit d3308e2cfd9d8818c5663811e7ea9fd5b66be82f in PR #122948. It is present in beta tags beginning with v2026.8.1-beta.2; stable v2026.7.1-2 predates it.
There is one accepted residual. A started read can briefly observe a missing nextRunAtMs, but the scheduler-owned timer repairs it within the existing 60-second watchdog cadence. That tradeoff keeps read RPCs write-free while preserving bounded repair.
Evidence From The PR
The before-and-after evidence is unusually concrete:
- Four started read surfaces over 100 stable jobs previously performed four
cron.schedule-unownedtransactions; after the fix, they performed zero. - Stable-future, event-driven no-next, and active-due timer cases each previously performed a maintenance transaction; after the fix, they performed zero.
- A 100-job repair previously performed 100 active-receipt queries; after the fix, it performed one.
- The focused post-fix suite covered 9 files and 122 tests.
The change also batches active receipt lookups inside the existing transaction. Receipt-owned jobs remain untouched, while missing schedules, stale backoff slots, overdue execution, retries, and auto-disable behavior continue to work.
The Takeaway
This is not a flashy feature, but it is an important production hardening patch. Cron is one of those OpenClaw subsystems that quietly supports reminders, retained jobs, system checks, and operator workflows. Keeping its read path lightweight reduces the chance that observability itself becomes load.
For users running recent beta builds with large cron stores or frequent dashboard polling, this fix should make cron inspection feel more like a read and less like an accidental maintenance window.