Scheduled triggers

What you’ll know by the end of this check

• Which preset cadences are built in (and which require dropping to cron)
• Why the minimum interval is one hour — and what that rules out
• How to read the cron expression your CLI wrote

The shortest possible answer

A schedule trigger runs the routine on a recurring cadence. Pick one of these presets in the web form or via /schedule in the CLI:

• Hourly
• Daily
• Weekdays
• Weekly

Times are local. The cloud converts to wall-clock automatically. Runs may stagger a few minutes after the scheduled time (see Jitter below).

Minimum interval: one hour. Anything more frequent is rejected. If you need every-minute execution, you’re looking at the wrong tool — see /loop or Desktop scheduled tasks.

Reading the cron expression

When the CLI writes a routine, it converts your natural-language description into a standard 5-field cron expression: minute hour day-of-month month day-of-week.

Day-of-week uses 0 or 7 for Sunday through 6 for Saturday. Extended syntax (L, W, name aliases like MON) is not supported. When both day-of-month and day-of-week are constrained, a date matches if either field matches — standard vixie-cron semantics.

Custom intervals

If none of the presets match (e.g. “every two hours” or “first of each month”), the play is:

1. Pick the closest preset in the web form.
2. In the CLI, run /schedule update and set the exact cron expression.

The web form doesn’t accept raw cron strings. The CLI does.

Jitter: why your 9am job fires at 9:03

To avoid every session hammering the API at the same wall-clock moment, the scheduler adds a small deterministic offset:

• Recurring tasks fire up to 10% of their period late, capped at 15 minutes. An hourly job lands anywhere from :00 to :06.
• One-shot tasks on the top or bottom of the hour fire up to 90 seconds early.

The offset is derived from the routine’s ID, so the same routine always gets the same offset. If exact timing matters, pick a minute that isn’t :00 or :30 (e.g. 3 9 * * * instead of 0 9 * * *), and the jitter won’t apply.

What scheduled triggers are good for

• Backlog maintenance — weeknight issue-grooming, label-applying, owner-assigning.
• Docs drift scans — weekly sweep of merged PRs that changed APIs, open doc updates.
• Morning digests — daily “here’s what happened in the repo since yesterday.”
• Weekly teardowns — every Sunday, archive stale branches, prune dead feature flags.

Pattern: unattended, repeatable, tied to a clear outcome. If it feels like “someone should do this weekly but no one ever does,” it’s a schedule trigger candidate.

Things to try right now (10 minutes)

1. Run /schedule list in Claude Code to see any routines you’ve already created.
2. Run /schedule update on one and look at the actual cron expression it generated.
3. If the minute is :00 or :30, change it to :03 or :33 to opt out of jitter.

The canonical version

Full official docs: code.claude.com/docs/en/routines.

Ready to verify this check?

You can read a cron expression without Googling. You know why hourly is the minimum and when to pick Desktop tasks or /loop instead. Mark it cleared.