OpenClaw's automation layer picked up another reliability fix in PR #112766, which hardens cron pacing, on-exit job lifecycle handling, and Gateway shutdown behavior. The merge is notable because the reported failures were reproduced on a live isolated Gateway with a real OpenAI-backed agent before the fix landed.
This is not a flashy feature. It is the kind of infrastructure patch that determines whether scheduled work is trustworthy when agents are allowed to run unattended.
Three Failure Modes
The PR describes three concrete cron automation failures.
First, a paced cron agent could fail an entire run after calling next_check with its own explicit job ID, even though omitting the same ID succeeded. That is a subtle contract bug: a tool that should let a job schedule its next check rejected a valid self-reference.
Second, an on-exit job could persist its terminal disabled state and cancel its own watcher before the payload entered the normal run pipeline. The practical result was worse than a failed run: there could be no history row explaining what happened.
Third, Gateway shutdown could return while an active cron command process tree kept running in the background. If that process later completed side effects, the Gateway had already told the operator it was done shutting down.
Taken together, these are exactly the kinds of edge cases that make operators nervous about automation: pacing can fail unexpectedly, event-driven jobs can disappear from history, and shutdown can leave work behind.
What Changed
The next_check path now accepts either an omitted job ID or the exact current job ID, while still rejecting cross-job attempts. That preserves the security boundary while allowing the current job to name itself explicitly.
The on-exit path now uses an ownership-safe per-transition fence plus an optimistic job precondition. That prevents terminal-state persistence from canceling the job's own fire or hiding concurrent edits.
Gateway shutdown now aborts registered active cron runs and drains them alongside stream teardown before completing its bounded shutdown path. The important part is sequencing: shutdown should not declare success while cooperative cron command processes are still capable of completing normal side effects.
Why It Matters
Cron is becoming one of OpenClaw's central control planes. The same day, OpenClaw also moved heartbeat monitors into system-owned cron jobs, making cron responsible for even more recurring automation. That raises the bar for correctness. A cron service cannot just start jobs; it has to preserve identity, pacing intent, history, cancellation, and shutdown semantics.
This patch strengthens those guarantees in places where real-world automation tends to fail: self-scheduling, event transitions, and service teardown.
Live Validation
The PR includes unusually practical proof. The author ran live OpenAI pacing with openai/gpt-5.6-luna and confirmed a persisted next run exactly 120,000 milliseconds after completion. A live on-exit test produced exactly one successful run with exit reason exit. A live shutdown test showed the command child received SIGTERM, died before Gateway return, and did not write a normal-completion marker.
The automated evidence is broader as well: 251 focused assertions passed on latest main, plus Blacksmith Testbox scenarios and 678 cron/Gateway tests. Formatting, lint, typechecks, plugin boundaries, import cycles, database and schema guards, and git diff --check also passed.
The Operator Takeaway
For users who rely on OpenClaw cron jobs to check queues, run maintenance, poll services, or perform paced external work, this is a confidence patch. next_check is less brittle, on-exit jobs are more accountable, and Gateway shutdown is less likely to leave background command work drifting past service exit.
It is also a sign of where OpenClaw is heading. Automation is no longer a side feature. It is becoming shared infrastructure, and the project is treating lifecycle correctness as part of the product.