Three tools, three failure modes if you pick wrong:

| | /schedule | /loop | crontab | |---|---|---|---| | Persistence | Yes (cloud, survives restart, runs while laptop sleeps) | No (session-scoped, dies on exit) | Yes (your machine) | | Where it runs | Anthropic cloud | Your local Claude Code session | Your machine | | Runs an LLM prompt | Yes | Yes | Possible but you wire it yourself | | Runs a shell command | Indirectly (prompt calls Bash) | Same | Yes, native | | Cadence input | Cron preset, custom cron, natural language | cron expression or 5m shorthand | cron only | | Trigger types | Schedule, API, GitHub events | session-only | cron only | | Off-machine | Yes | No | No (use systemd timers / remote scheduler) | | Min. interval | 1 hour | seconds | 1 minute |

Pick /schedule for anything that should keep running across days even when you are not in a session: morning brief, weekly memory consolidation, daily PR digest, on-deploy verification. Pick /loop for short-lived "keep checking until X is done" patterns inside one session: /loop 5m check the deploy while you wait on a build, then exit. Pick crontab for shell scripts where the LLM is not in the loop (database backups, log rotation, certificate renewals).

A schedule earns its keep when:

• You actually need the work done (you skip it manually about half the time, automate it)
• The output is short and read-once (a brief, an alert, a status email, not a 50-line report you would skim and forget)
• It runs often enough that drift matters (daily, weekly, not monthly, monthly is too rare to get a routine going)

Three good first picks:

• Morning brief at 08:30 weekday mornings (Recipe 5.1)
• Weekly memory cleanup Sunday 18:00, runs nex_consolidate plus nex_deduplicate plus nex_decay stats
• Friday retrospective Friday 17:00, runs nex_synthesize over the week, writes one summary

Pick one. Build confidence with one before adding three more.

In any Claude Code session:

/schedule

Claude opens a conversation that asks for a name, a schedule (cron-style or natural language), a prompt, the repositories to clone, and which connectors to include. You can also pass the description directly:

/schedule daily 08:30 run the morning-brief skill and post the output to Telegram

For one-off runs (single fire at a future time):

/schedule in 2 weeks, open a cleanup PR that removes the feature flag
/schedule tomorrow at 9am, summarize yesterday's merged PRs

The CLI creates scheduled routines only. To add an API trigger or a GitHub trigger to the same routine, edit it in the web UI at claude.ai/code/routines.

The routine is stored in your claude.ai account, not in a local file. It is account-scoped, not project-scoped, so a routine you create in one project shows up in all your sessions and in the web UI.

Three more /schedule subcommands work in any session:

/schedule list      # see all your routines
/schedule update    # edit a routine
/schedule run       # fire one immediately, without waiting for the next scheduled time

For full control (API tokens, GitHub events, branch-push permissions, environment variables), use the web UI at claude.ai/code/routines. API and GitHub triggers can only be added there, not from the CLI.

Run academy_validate_step. The cron_routine_active validator looks for a crontab -l line, which is the only signal it can read locally. /schedule routines live in the Anthropic cloud, not on your filesystem, so the validator cannot detect them automatically. If you have a /schedule routine running, pass manual: true to mark this step done.

Either path counts.

Routines do not fire on round-minute boundaries. Anthropic adds a stagger to each routine's actual fire time, and the offset is consistent for that routine. So 0 9 * * * does not fire at 09:00:00 sharp. It fires a few minutes later at the same offset every day.

This matters because if every customer scheduled their daily job at 09:00:00, half the world's API calls would hit at the same instant and you would get rate-limit storms. The stagger spreads the load.

For raw crontab on your own machine you do not get this for free. Best practice: pick odd minutes deliberately. Instead of 0 9 * * *, write 13 9 * * * or 27 8 * * *. Anti-stampede default.

A one-off schedule (/schedule tomorrow at 9am, ...) fires the routine once at that timestamp, then auto-disables. The web UI marks it as Ran. Two important properties:

• One-offs do not count against the daily routine cap. A normal scheduled routine has a per-account daily run allowance. One-offs draw from your subscription usage like any other session, but they are exempt from the daily routine cap.
• They survive client restarts and your laptop being asleep, because routines run on Anthropic infrastructure.

Use one-offs for "remind me later this week to verify X" or "in 2 weeks, open a cleanup PR for the feature flag we just shipped".

Routines run on Anthropic infrastructure, so they do not depend on your laptop being alive. The common failure modes are different from local cron:

• The prompt failed silently. Check the run history in the web UI at claude.ai/code/routines. The most common failure is "tool was renamed and the prompt still uses the old name", or "connector got removed and the prompt needs it".
• You hit your daily routine cap. Each account has a per-day routine run allowance. If many routines compete and one fails to fire, check the cap on claude.ai/settings/usage. Organizations with extra usage enabled can run on metered overage.
• The routine wants a connector you do not have. Routines clone repos and use connectors at run time. If you removed a connector after creating the routine, the run fails. Re-add the connector or edit the routine.
• You expected an event-trigger but only set a schedule. API and GitHub triggers must be added explicitly via the web UI. The CLI only sets up scheduled triggers.

What you do NOT schedule

• Anything that needs human judgment in the loop (PR reviews where you would accept or reject, customer responses, hiring decisions)
• One-off cleanup that is technically recurring but realistically you only do twice a year (annual audit, certificate renewal, leave those manual)
• Anything where a missed run is silent and bad. Schedules can fail silently. For "must-run" tasks with monetary or safety consequences, build alerting on top, do not rely on /schedule alone.

The right things to schedule are small, low-risk, high-frequency tasks where seeing the output is the point. Start with one, add the second after two weeks.

Source

The behaviour above comes from the official Anthropic documentation at code.claude.com/docs/en/routines. If a flag, file path, or subcommand is not described in that page, it does not exist.