OpenClaw cron
Scheduled background jobs (mcp__openclaw__cron) that spawn their own session and run autonomously — daily self-improvement cycles, nightly job-hunt digests, apartment-search sankeys.
Dogfooded continuously since at least 2026-08-08 through the daily 6am self-improving cycle (this entry is being written by one), plus two nightly report jobs (job-opportunities-sankey-daily, apartment-hunt-sankey-daily).
Goals
Run recurring prompts on a schedule, in an isolated session, without a human in the loop — the daily self-improvement reflection, nightly job-hunt and apartment-hunt sankey digests, PR watchers, and similar. The job's own session should be inspectable later to confirm it ran and see what it did.
Effectiveness
Adequate, with a real asymmetry. The scheduling itself is solid: jobs have fired on time, every day, for at least five days straight, with real side effects (files written, emails checked, reports delivered). But a session spawned by a cron job cannot see the real mcp__openclaw__cron tool at all — ToolSearch only ever resolves the session-scoped CronList/CronDelete built-ins, which track jobs created via CronCreate in-session and see zero of the actual persistent jobs. Confirmed independently five days running (2026-08-08 through today), across different jobs and different sessions. A cron job cannot list itself, disable itself, or edit its own stored step definition — any of that requires a human, or an agent, acting from an unrelated live session that happens to expose the real tool.
What made it effective
- Genuinely reliable firing: the two nightly report jobs and the daily self-improving cycle have never missed a day.
CronList action=list includeDisabled=truefrom a session that does expose the real tool is a clean, authoritative source of truth — the failure mode is specifically about which sessions get access, not the tool's own design.- Side effects land where they should: a job that emails a report, writes a file, or pushes a commit does so reliably even when the executing session can't introspect itself.
Friction, pain points, surprises
A cron session can't act on itself. job-opportunities-sankey-daily's render step has shelled out to the now-removed rtk binary since 2026-08-13, and every run since has silently worked around it with a PUPPETEER_EXECUTABLE_PATH fallback rather than actually fixing the stored step — because the session doing the work has no path to mcp__openclaw__cron's edit capability to fix its own definition. Same story for an unrelated PR-watcher job that confirmed its own watched PRs had merged and tried, and failed, to disable itself three days running. The fix has to come from a session outside the loop.
A three-day "silent failure" that wasn't. Two report-generating cron jobs left nothing but a two-line stub in their own session file — handoff prompt in, no assistant response ever written back — which read, for three consecutive daily reviews, as jobs silently dying mid-run. Cross-referencing message-level timestamps resolved it today: the actual completed reports (an evening job-hunt digest, an apartment-search sankey image) appear a few minutes later in the destination channel's session (the main WhatsApp thread), not in the cron run's own file. The work was never failing — the output is delivered to wherever the job messages the user, and the cron session itself simply never gets the assistant's final response appended to it. Auditing "did this job actually run" from the cron session alone will get the wrong answer; the real record lives in the channel it reported to.
Verdict: adequate. The scheduler does its one job — fire prompts on time, autonomously, for real work — without a single missed cycle observed. But a cron-spawned session is structurally blind to the tool that manages its own kind, which turns "the job needs a one-line edit" into "flag it and wait for a human," and turns "did it run" into a small forensic exercise across two different session files.