Creating and managing automations
Creating and managing automations
Automations is now the user-facing name in the agent tool, Control UI, command line, and docs, while
openclaw automations offers the same command family as openclaw cron. The old command, /cron route, cron.* settings and RPC names, schedule expressions, identifiers, and stored jobs continue to work.The Control UI is the fullest place to search, filter, create, clone, inspect, edit, run, pause, and remove automations, including advanced delivery and failure routing. New Quick Create and starter automations stay internal unless you explicitly choose an Announce summary and its destination. iOS and Android expose the fields and actions each client supports, Android changes require administrator scope while read-scoped connections remain inspection-only, and script automations remain visible but read-only on clients that cannot replace their payload.Schedules and runs
Schedules and runs
An owner can turn the current conversation into a
/loop or eligible reminder that checks a small amount of recent context when it runs and returns one final answer to the same chat. It starts as a fresh run rather than continuing the original transcript, and work created without a conversation stays isolated.Recurring schedules, one-time jobs, manual starts, queued work, restart catch-up, on-exit work, commands, and bounded scripts now share one configured capacity limit. Waiting work starts as room becomes available, while successful scripts can retain a small amount of state, notify a destination, wake the main conversation, or ask to be checked again later. Scripts still have time, tool-call, pacing, and state limits, and can be disabled entirely.Force runs and edits no longer pull recurring work away from its natural schedule. Timezone-aware schedules skip local times that never occur, choose the first real occurrence when a local time repeats, and continue to respect explicit offsets after a restart.Triggers and connected tools
Triggers and connected tools
An automation can now wait for a condition or monitored event stream and run when something changes. Conditions can be created, filtered, edited, and inspected in the Control UI, are checked before they are saved, and record checks and matches without creating a run for every non-match. Stream schedules are created through the command line or agent and remain read-only in the Control UI, with bounded buffering, batching, and restart backoff. Triggers can still be disabled entirely, and condition intervals must be at least 30 seconds.New or reauthorized Codex jobs can keep the app permissions and eligible connected-tool access they were created with across restarts. That captured authority is a ceiling checked on every run against current accounts, configuration, policy, approvals, and availability. Tools requiring someone present to approve them stay excluded, existing limits do not expand automatically, and some older jobs need a one-time edit or reauthorization before they can retain this access.
Heartbeats and email watchers
Heartbeats and email watchers
Heartbeat schedules are now managed as Automations, with failed work and alerts remaining visible and retryable and queued wakes surviving busy periods, handler replacement, and clock changes. Disabling Cron stops scheduled heartbeats while manual and event-driven wakes remain available. Existing installations using
HEARTBEAT.md must run openclaw doctor --fix to migrate valid work because OpenClaw no longer reads that file at runtime.Gmail can split an accepted batch into one isolated run per message when its mapping opts in, filter Sent and Draft mail, and keep forwarding through watcher restarts without overlapping renewals or repeated restart loops. Ordinary custom mappings keep their existing behavior, and expired-OAuth renewal health is unchanged.The bundled IMAP watcher lets authenticated new mail from an existing mailbox start a restricted reader agent without exposing an HTTP hook. It is disabled by default and inbound-only, requires sender allowlisting and authentication, and cannot send or modify mail. After three temporary admission failures, the message is recorded as skipped.History, alerts, and delivery
History, alerts, and delivery
Automation history now treats running the work, delivering its result, and completing the whole request as separate facts. A job can execute successfully while the request still fails because requested delivery did not settle, and delivery is required unless best-effort is explicitly selected. Current-session work on a web-only Gateway counts the durable conversation result as completion when there is no external route, while an unavailable named route remains a delivery error without rerunning work that already completed. A successful delivery retry clears an earlier transient error, and intentional suppression is shown with its recorded reason in the command line and Control UI instead of looking like a failed delivery. Primary webhooks record accepted or failed outcomes before finalization, while secondary completion webhooks remain detached fan-out.History can show duration, token totals, cache counters, condition checks and fires, delivery traces, cancellation or failure reasons, and direct Inspect links from eligible visible notifications. Inspect links require
gateway.publicOrigin, historical rows may not have every optional counter, and condition activity belongs to the job’s history rather than the global feed.Failure alerts use configurable routes, thresholds, and cooldowns, with route-backed alerts defaulting to two consecutive failures and a one-hour cooldown. Recurring cron or every jobs disable themselves after ten consecutive execution failures and explain how to re-enable them, while delivery-only failures do not advance that streak and a successful run or manual re-enable resets it.Automations After a Restart
Automations After a Restart
Restart recovery now distinguishes work that was genuinely missed from work that already finished or no longer belongs to the current automation. Queued and deferred runs, rescheduled one-time reminders, schedule times missed during a restart or clock change, and interrupted one-shot jobs without a terminal result can return under normal catch-up pacing. Attempts with a durable terminal result do not replay, and completed slots, deleted or retired jobs, old schedules, and work from a replaced scheduler stay retired.Current edits, self-removal, and rescheduling are preserved during startup, concurrent scheduler work no longer overwrites sibling jobs, and damaged older rows remain available for Doctor. Failed or skipped one-shot recovery remains disabled for inspection, while a successful job configured with
deleteAfterRun is removed normally. Legacy running markers still remain interrupted when they cannot establish whether an outside side effect happened, so exactly-once execution in external systems remains outside the scheduler’s recovery boundary.