Scheduling Recurring Team Work with Clawboo Routines

A Routine is a scheduled team task: a trigger — either a cron expression for recurring work, or a one-shot once@<ISO-8601> for a future-dated task — that materializes a board task and dispatches it through the same pipeline as any other task. Routines are how your team gets recurring or future-dated work done without anyone sitting at the dashboard to kick it off. Every Routine fire is a real task dispatch: it lands on the board, gets atomically claimed, and runs with budgets, verification, approvals, and observability all applying exactly as they would for a hand-created task. There is no special “scheduled” execution path.

​

What Routines are (and aren’t)

Routines are Clawboo’s cron for team tasks. They are the single scheduling surface for every runtime class — native agents, Claude Code, Codex, Hermes, and OpenClaw all schedule recurring work through Routines, regardless of whether the underlying runtime has its own scheduler. Routines are not the same as a runtime’s own life-cycle scheduler. If an OpenClaw agent has a Gateway cron that wakes itself to check email, that is the agent’s private business — it appears in the Scheduler panel as a separate runtime-own-life entry and Clawboo never fires team tasks into it. The two are surfaced side by side and clearly labeled so you always know who owns what.

​

Creating a Routine

Open the Scheduler panel from the dashboard sidebar. Click New Routine and fill in: Click Save. The Routine is immediately active — no restart required.

​

How Routines survive restarts

Clawboo stores every Routine’s state — next fire time, last fire time, status, last error — durably in a database table. The scheduler is a stateless actuator that reads from the database: kill the process, restart it, and every active Routine reconstructs automatically from the stored rows. You do not need to re-create or re-arm Routines after a restart. On restart, Clawboo heals any Routines that were mid-fire when the process died:

• A fire that hadn’t started yet (claimed but not dispatched) is re-queued and fires immediately.
• A recurring fire that was running is re-armed at its next occurrence — the board’s own orphan reconciliation handles the half-dispatched task.
• A one-shot fire that was running moves to error for human review rather than re-firing, since re-firing a one-shot risks dispatching it twice.

​

Pausing and deleting Routines

From the Scheduler panel, select any Routine to:

• Pause — the Routine stops firing until you resume it. Already-running tasks complete normally.
• Resume — re-arm the Routine from now; it fires on its next scheduled occurrence.
• Delete — remove the Routine entirely. In-flight tasks continue to completion.

​

The error-halts policy

When a recurring Routine’s task fails, the Routine stops firing and waits for you. It moves to an error state, records the failure details, and sets no next fire time. It will not retry automatically. This is intentional. A Routine that fails on every fire and keeps retrying would spend budget, churn the board, and bury the real problem. Parking the Routine surfaces the failure clearly and stops the spending. The Scheduler panel shows the error and a Resume button — fix the underlying issue, then resume to re-arm. A successful fire re-arms cleanly at the next cron occurrence. A one-shot fire that succeeds simply expires.

​

Routine status reference

​

Observability for Routines

Every Routine fire emits a sequence of events to the observability event log:

• routine_fired — when the scheduler claims the fire
• routine_dispatched — when the task is materialized and handed to the executor
• routine_completed — when the task finishes successfully
• routine_error — when the task fails and the Routine is disarmed

You can view the full history of a Routine’s fires in the Observability Dashboard by filtering for routine_* events on the relevant team or task.

Advanced: cron expression formats

Clawboo accepts standard 5-field cron expressions (minute hour day month weekday) and 6-field expressions with seconds (second minute hour day month weekday). Examples:

Expression	Meaning
0 9 * * 1-5	Weekdays at 9:00am
0 0 * * 0	Sundays at midnight
*/15 * * * *	Every 15 minutes
0 0 1 * *	First day of every month at midnight
once@2025-06-01T10:00:00Z	Once at 10am UTC on June 1, 2025

All times are interpreted in UTC unless your cron expression specifies otherwise.