Choosing the Right OpenClaw Automation Mode

Think of OpenClaw automation like running a workshop. A wall clock tells people when to start. A floor manager notices when something needs attention. A door sensor reacts when someone walks in. A clipboard records what got done. A production board coordinates the multi-step jobs. The company handbook defines who is allowed to do what.

That is basically the split here. Cron is the wall clock. Heartbeat is the floor manager. Hooks are the door sensors. Tasks are the clipboard. Task Flow is the production board. Standing orders are the handbook.

The official automation docs and scheduled tasks docs point to the same practical lesson: pick the control surface that matches the real trigger and the real reliability need. Do not make cron impersonate everything else just because it is the first tool you learned.

This page is a router, not the full manual for every automation surface. Once you know which lane fits, use the deeper companion pages for the actual implementation details.

The short router first

Use cron when timing matters more than ambience

Cron is for precision. A reminder in 20 minutes, a report every weekday at 7 AM, a weekly review every Monday, a webhook-triggered isolated run. That is cron territory.

The key detail many people miss is that cron answers the when question, not the whole workflow question. It wakes the agent at the right time, can deliver output to a chat or webhook, and every cron execution creates a background task record.

That last point matters. If you care about auditability, detached delivery, or run history, cron gives you a clean operational trail by default.

Cron execution style changes the feel of the job

This is where a lot of operator pain comes from. People say, "cron lost my context," when what they really mean is, "I picked isolated for a workflow that should have used a named session." Slightly different complaint, much more useful fix.

# exact timing, fresh run every morning
openclaw cron add   --name "Morning brief"   --cron "0 7 * * 1-5"   --tz "Europe/Berlin"   --session isolated   --message "Summarize overnight updates."   --announce

# exact timing, but keep deliberate shared history
openclaw cron add   --name "Weekly project review"   --cron "0 9 * * 1"   --session session:weekly-review   --message "Continue the standing weekly review process."

Use heartbeat when the work should feel like periodic awareness

Heartbeat is not a second-rate cron. It is a different idea.

Heartbeat runs periodic turns in the main session, usually every 30 minutes by default. Timing is approximate. The value is not precision. The value is that the agent can batch checks, notice background completions, and surface what matters without creating a detached job for every tiny routine glance.

• Good fit: inbox checks, calendar awareness, reminder surfacing, quiet follow-up loops
• Bad fit: "run exactly at 08:00" or anything that needs strong scheduling guarantees

One subtle but important rule: heartbeat turns do not create task records. If you want a ledger of detached work, heartbeat is the wrong lane.

A good shortcut is this: if the task sounds like "keep an eye on this," heartbeat is probably the right first thought. If it sounds like "fire at this exact time," it is probably cron.

Tasks are the ledger, not the scheduler

This is the concept people flatten most often. Tasks feel operational, so beginners assume tasks must be the place where work gets scheduled. The docs are explicit: tasks are records, not schedulers.

They track detached work such as ACP runs, subagent spawns, cron executions, and CLI operations. They tell you what ran, when it started, whether it succeeded, failed, timed out, or got cancelled.

That separation is healthy. Scheduling and tracking are related, but they are not the same concern. One decides when the work happens. The other tells you what happened after it did.

• Cron decides when a detached scheduled run starts
• Tasks record the run lifecycle
• Heartbeat can react to completed work, but does not become a task itself

If you remember one sentence from this section, let it be this: tasks explain the aftermath.

Task Flow is what you use when one task is not the whole story

A plain task is fine for one background operation. Fetch data. Render a file. Run a detached analysis. Done.

Task Flow is for work that has structure: step A, then B, then C, maybe with waits, retries, approvals, or mirrored external progress. It sits above tasks and keeps durable flow state across gateway restarts.

The practical difference is simple. If you are asking, "Did the background run finish?" you are in tasks land. If you are asking, "Which stage is the workflow in, and what happens next?" you are in Task Flow land.

Think of tasks as package tracking for one parcel. Think of Task Flow as the warehouse board for a whole shipment moving through multiple stations.

Hooks are for events, not schedules

Hooks are the right answer when something inside OpenClaw should trigger the automation. A /new command, a /reset, a startup event, a shutdown event, message receipt, message send, session compaction, and so on.

This matters because event-driven automation is cleaner when it stays event-driven. If you need to run a small action after message:sent, polling every few minutes would be a ridiculous way to find out. The event already happened. Use the event surface.

Also, do not blur internal hooks with inbound HTTP webhooks. They sound related because the names are annoyingly similar. In OpenClaw docs, hooks here means internal gateway events. Webhooks are external HTTP trigger endpoints.

Standing orders answer "what am I allowed to do?"

Standing orders are the durable operating rules. They usually live in AGENTS.md so they get injected into every session automatically.

Cron is usually the timer. Standing orders are the playbook.

This is a better pattern than stuffing everything into a cron prompt. Why? Because the schedule should not have to carry the whole policy brain of the workflow. When authority, escalation rules, and limits live in standing orders, each scheduled prompt can stay short and clear.

• Standing order: own the daily inbox triage, escalate unknowns, do not send external replies without approval
• Cron prompt: execute the inbox triage per standing orders

Cleaner. Easier to review. Much less likely to drift when you update the workflow later.

A practical decision tree

1. Do you need exact timing? Use cron.
2. Do you just need periodic awareness? Use heartbeat.
3. Did an internal event trigger the action? Use hooks.
4. Do you need a record of detached work? Tasks will track it.
5. Does the job have multiple durable stages? Add Task Flow.
6. Does the agent need durable authority or guardrails? Put that in standing orders.

Notice how these answers stack instead of competing. A mature automation often uses more than one surface at once.

• standing orders define authority
• cron defines timing
• tasks record the detached run
• Task Flow coordinates the multi-step stages

That is not duplication. That is separation of concerns doing its job.

Common wrong picks

• Using cron for ambient checking: you end up with too many detached runs and not enough shared context
• Using heartbeat for exact reminders: the timing gets mushy because heartbeat is approximate by design
• Treating tasks like a scheduler: you get a nice ledger and no timing logic
• Using hooks for long workflow orchestration: event triggers are not the same thing as durable multi-step state
• Stuffing all rules into cron prompts: the workflow becomes harder to audit and easier to contradict later

The short version

If timing is the problem, start with cron. If awareness is the problem, start with heartbeat. If an event should trigger the action, use hooks. If you need tracking, tasks are the ledger. If the workflow has stages, add Task Flow. If the agent needs ongoing authority, define standing orders.

OpenClaw gives you several automation surfaces because real operational problems are different from each other. That is not clutter. That is the platform refusing to pretend one hammer should fix every screw.