You check your deployment status every 30 minutes by switching terminals. Claude can do it for you — poll a URL, parse the response, and alert you when something looks wrong — all without leaving your current session.
Why Scheduled Tasks?
Scheduled Claude runs power: nightly doc generation (sync README from code comments), daily PR summaries (digest activity across repos), hourly dependency checks (alert on new CVEs), weekly cost reports (aggregate billing data). Automation that runs on a timer, not on your memory.
Claude Code can run prompts on a schedule without leaving your session. The /loop command and the underlying CronCreate tool (cron is a Unix utility for scheduling recurring tasks) 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 API surface here is small — see CI/CD Integration for pipeline-based scheduling and Ready-Made Automations for cron-ready scripts.
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 statusCreate a scheduled task in your current session:
In an interactive Claude session, type: /loop 2m tell me the current time and a fun fact
Watch it fire twice, then cancel it. Notice how the task runs in the background of your existing conversation — no separate terminal needed.
Listing 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, 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.log 2>&1 || echo "Claude failed at $(date)" | mail -s "Cron Alert" [email protected]Production cron jobs should:
- Log to file (
>> /tmp/deploy-check.log 2>&1) - Check exit codes (
|| alert_on_failure) - Alert on failures (email, Slack, PagerDuty)
See the CI/CD chapter for retry patterns and exponential backoff.
Scheduled 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.
Common mistake: running Claude every minute. Most tasks work fine hourly or daily. Over-scheduling wastes tokens (startup overhead every run) and hits rate limits. Start with hourly, measure actual freshness needs, then tighten intervals only if required. A PR summary every 30 minutes costs 48x more than once daily — is the extra freshness worth it?
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.
In your next interactive Claude session, try /loop 5m check if there are any new commits on main. Let it run while you work on something else. Scheduled tasks turn Claude from a tool you invoke into an assistant that watches things for you.