Claude Code can run prompts on a schedule without leaving your session. The /loop command and the underlying CronCreate tool let you poll deployments, babysit PRs, check builds, and set reminders — all from the same terminal where you are already working. Tasks are session-scoped, so they vanish when you exit.
The /loop Command
The quickest way to schedule a recurring task is /loop. Give it an interval and a prompt, and Claude starts firing on that cadence.
The interval can lead or trail the prompt, and it defaults to 10 minutes when omitted:
/loop 5m check if the deployment finished/loop check the build every 2 hours/loop check the build # defaults to 10 minutesSupported time units are s (seconds, rounded up to 1 minute), m (minutes), h (hours), and d (days). Intervals that do not divide evenly into standard cron periods (like 7m) are rounded to the nearest clean interval, and Claude tells you what it picked.
CronCreate Tool
For finer control, use the CronCreate tool directly with a standard 5-field cron expression:
minute hour day-of-month month day-of-weekCron Expression Quick Reference
| Expression | Meaning |
|---|---|
*/5 * * * * | Every 5 minutes |
0 * * * * | Every hour on the hour |
0 9 * * * | Every day at 9am local |
0 9 * * 1-5 | Weekdays at 9am local |
*/15 9-17 * * 1-5 | Every 15 min during work hours, weekdays |
0 */2 * * * | Every 2 hours on the hour |
All times use your local timezone, not UTC. There is no way to specify a different timezone in the expression itself.
Example — check CI every 15 minutes during work hours on weekdays:
CronCreate: */15 9-17 * * 1-5 check CI pipeline statusListing and Deleting Tasks
CronList shows every active task, its schedule, and when it will fire next:
Each task gets an 8-character ID. Pass that ID to CronDelete to cancel it. There is a per-session limit of 50 concurrent tasks.
Looping Over Skills
You can combine /loop with any slash command. Each time the task fires, Claude runs the skill as if you had typed it yourself:
This works with any skill — /review-pr, /commit, custom skills you have installed, and so on. It is especially useful for watching a PR during a long review cycle or monitoring a build that takes time to converge.
Session vs Durable Scheduling
When to Use Each Approach
| Criteria | Session-Scoped (/loop) | External (cron / GitHub Actions) |
|---|---|---|
| Survives terminal close | No | Yes |
| Survives machine restart | No | Yes |
| Setup effort | One line | Crontab or YAML workflow |
| Auto-expiry | 3 days | Never (runs until removed) |
| Max concurrency | 50 tasks per session | OS / CI limits |
| Best for | Babysitting a deploy, watching a PR, reminders | Nightly reports, health checks, recurring audits |
| Catch-up on missed fires | No — fires once when idle | Depends on scheduler config |
For durable scheduling that survives restarts, use system cron calling claude -p in headless mode, or a GitHub Actions workflow with a schedule trigger:
# System cron — runs even if Claude is not opencrontab -e# */5 * * * * claude -p "check deployment status" --output-format json >> /tmp/deploy-check.logScheduled tasks live inside the running Claude Code process. Closing the terminal, exiting the session, or losing your SSH connection cancels every task instantly. There is no persistence file, no catch-up, and —no-session-persistence has no effect. If you need scheduling that outlasts your terminal, use system cron or GitHub Actions instead.
Cron granularity is 1 minute minimum. If you write /loop 30s check the build, Claude rounds it up to 1 minute and tells you so. There is no sub-minute scheduling. For intervals that do not divide evenly into standard cron slots (like 7m), Claude rounds to the nearest clean interval (e.g., 5 minutes) and reports what it chose.
Jobs scheduled on the hour (:00) or half-hour (:30) get up to 90 seconds of jitter to prevent thundering-herd effects. Use odd minutes like :03 or :17 to avoid it: CronCreate: 3 9 * * * morning check.