Automations let Operator run recurring work on a schedule. They do not live inside one instance.
Use automations for manager level work
Good fits:
- Check all active instances every morning
- Restart a fleet on a maintenance schedule
- Generate a daily summary from agent activity
- Message one or more instances as part of a recurring workflow
Bad fits:
- Cron that should live inside one instance
- Jobs that should be stored in
.openclaw/cron
Use local instance cron for those.
How automations work
Each automation stores:
- A name
- A prompt
- A 5 field cron expression
- A timezone
- An enabled or disabled state
When it runs, Operator calls the manager with the stored prompt. The manager can inspect instances, change config, grant secrets, or message agents as part of the run.
Operator uses standard 5 field cron syntax:
minute hour day-of-month month day-of-week
| Schedule | Cron |
|---|
| Every hour | 0 * * * * |
| Every 6 hours | 0 */6 * * * |
| Daily at 9 AM | 0 9 * * * |
| Weekdays at 9 AM | 0 9 * * 1-5 |
UTC if you do not send one.
Example automation prompt
Check every active instance.
If one has been suspended or is failing, summarize the issue.
If one needs a restart, restart it.
Then post a short report in this chat.
Automation versus local cron
Use this rule:
- If the schedule belongs to the Operator manager, use an automation.
- If the schedule belongs to one instance, create local cron inside that instance.
Examples:
- “Every morning, review every active instance and send me a report” is a manager automation.
- “Every morning, have Research Desk post a summary” is local cron inside that instance.
Do not convert an instance cron request into a manager automation just because both are scheduled work.
