Managing OpenClaw automations

Once jobs exist, someone has to list them, nudge them, read their history and change them without breaking their authority model. OpenClaw’s automation management is a CLI with a handful of verbs, a conversational path for administrators in the Control UI, and a small set of configuration keys. Here are the docs’ recipes, the two management paths and their authority rules, the run history semantics that explain a job that ran but did not deliver, the flag rules, the model override notes, the configuration, and how retries and retention behave.

Recipes and paths

• Five recipes: a one-shot calendar check in twenty minutes as a main-session system event with an immediate wake; a recurring isolated morning brief at seven in a timezone announced to a Slack channel; a weekly deep analysis with a model and high thinking; a weekday deploy digest posted to a webhook; and a queue-depth probe running a command every fifteen minutes and announcing to a Telegram chat.
• In the authenticated Control UI an administrator can ask the agent to list, inspect, update, run or remove any automation on the Gateway regardless of creator or channel; the Gateway grants that from the turn’s admission facts as a one-use grant that expires after sixty seconds and stays bound to the active run, channel turns and non-admin turns get no grant, and each request is logged with its method, run and outcome.
• The CLI lists enabled jobs or all of them, gets a job as JSON, shows it with its resolved delivery route, enables and disables without deleting, edits, forces a run now, waits on a forced run with a timeout and poll interval and exits zero only on a succeeded completion, runs only if due, views run history or one exact run, removes, and selects or clears the agent on multi-agent hosts; the doctor fix repairs older jobs missing creator metadata only when the stored identity proves the account.
• Archiving a session disables every enabled job bound to it, its isolated per-job session, a session target or a delivery or wake lane, restoring the session does not re-enable them, and sessions with an enabled bound job show a clock badge in the sidebar.

Management authority does not transfer creator attribution or replace the job’s scheduled execution policy.

History and flags

Run-now delivery measures lateness from when the manual request was accepted, so an old pending scheduled slot does not make fresh output stale, and a manual run preserves the recurring cadence. History keeps payload execution in a status of ok, error or skipped and whole-run completion in a completion status of succeeded, failed or unknown: requested delivery is required unless the job explicitly opts into best effort, a delivery-only failure leaves execution ok without touching error counters or backoff while recording a failed completion, and an adapter send without a delivery identity stays unknown with no automatic resend. Intentional silence, empty output, heartbeat acknowledgements and channel reply transforms record a suppression reason without claiming delivery, one-shots that end that way are deleted normally, and retained one-shots never rerun on their own. The agent’s automations tool returns compact summaries, id, name, enabled, effective agent, next run, schedule kind and last run, with a get action for one full definition, and direct callers can ask the list call for the compact shape. Create is an alias for add and accepts a positional schedule and prompt; a webhook flag cannot combine with the chat delivery flags; on edit, clear flags unset channel, recipient, thread and account individually, distinct from the no-deliver flag that only disables runner fallback delivery. Model notes: the model flag sets the job’s primary and configured fallback chains still apply, a disallowed or unresolvable model fails the run with a validation error, the fallbacks flag replaces the configured chain for that job and an empty value makes the run strict, clear flags remove either override, and a plain model with no fallback list never falls through to the agent primary as a hidden retry.

Configuration and retention

• Keys: enabled, a triggers setting that switches condition scripts, script payloads and stream sources together, a webhook token sent as a bearer header since URLs must not embed credentials, the webhook SSRF policy that is strict when omitted, and a session retention of twenty-four hours by default for isolated run sessions; jobs, history and quarantined malformed jobs live in the shared SQLite database and the old store key is retired.
• A skip-missed-jobs setting makes recurring cron and every jobs advance to their next future occurrence after the Gateway was offline instead of catching up, at the cost of dropping missed work, while one-shots keep their catch-up either way; automations can be disabled entirely with the enabled key or an environment variable.
• One-shot retries follow a built-in schedule for transient errors while permanent errors disable the job immediately; recurring execution errors back off at thirty seconds, one minute, five, fifteen and sixty, resetting after the next success. Terminal run history is retained seven days, lost rows twenty-four hours, with the newest two thousand rows per job and history class as a ceiling, and the doctor fix imports legacy JSON job, state, quarantine and run files into SQLite, archiving the originals.

OpenClaw automations is the guide these verbs operate on, and OpenClaw doctor the command that repairs creator metadata, model retirements and legacy stores.

Where the records go

Every automation run also lands in the background task ledger silently, and a job bound to a session follows that session’s archive state. OpenClaw background tasks is that ledger, and OpenClaw sessions explains the archive and restore identity rules that decide whether bound jobs come back.

On Diali

On Diali the automations screen of the dashboard is the management surface, jobs and their run history live in the assistant’s state database on its volume, and the retention and retry defaults are the upstream ones. Hosted OpenClaw on Diali is the assistant and OpenClaw model failover the chain a per-job model still falls back through.

• Admin grants last sixty seconds and bind to one run.
• Status is the payload; completion status is the whole run.
• Seven days of history, two thousand rows per job.