Claude Code Scheduling: How to Automate Recurring Tasks with /loop, /schedule, and Cron

Claude Code is an incredibly capable coding agent when you're sitting in front of it. But some of the most valuable work it can do happens when you're not — monitoring deployments, reviewing overnight PRs, running daily security audits, or posting weekly code quality summaries.

The problem is that most developers don't realize Claude Code has a full scheduling stack built in. Not one mechanism but several, each designed for a different durability and access level. Pick the wrong one and your task dies when you close your terminal. Pick the right one and it runs reliably while you sleep.

This guide covers every scheduling method available in Claude Code, when to use each one, and how to set them up with practical examples.

The Three Scheduling Tiers

Claude Code offers three distinct ways to run recurring work. They differ in persistence, environment access, and setup complexity:

A fourth option — GitHub Actions — extends scheduling into CI/CD pipelines for team-wide automation. We'll cover that separately.

The rule of thumb: if you need something to run even when your computer is off, use cloud scheduled tasks. If you need access to local files and MCP servers, use desktop scheduling. If you're just monitoring something for a few hours during an active session, use /loop.

/loop — Session-Scoped Polling

The /loop command is the fastest way to set up a recurring task. It runs inside your active CLI session and repeats a prompt at a fixed interval.

Basic Syntax

/loop [interval] [prompt or slash command]

The interval accepts standard time units: s (seconds), m (minutes), h (hours), d (days). If you omit the interval, it defaults to every 10 minutes.

Practical Examples

Monitor a deployment:

/loop 2m check if the deployment on staging finished and tell me the result

Watch CI status:

/loop 5m check the latest CI run status on this repo and summarize any failures

Periodic code review:

/loop 1h review any new commits on the main branch since the last check and flag potential issues

Chain with other skills:

/loop 30m /simplify

When you invoke /loop, Claude parses the interval, sets up the recurring task, and confirms the cadence and task ID. Each iteration runs the prompt as if you typed it fresh.

Limitations to Know

• Session-bound. Closing the terminal or ending the session cancels all loop tasks immediately. There's no persistence across restarts.
• Idle-dependent. Loop tasks only fire when Claude Code is running and idle. If you're in the middle of a conversation, the loop waits until you're done.
• 7-day expiry. Tasks automatically expire and self-delete after 7 days.
• 50 task cap. You can run up to 50 concurrent scheduled tasks per session, which is more than enough for practical use.

When to Use /loop

/loop is ideal for real-time monitoring during active development sessions:

• Watching a deployment roll out
• Polling build status after pushing changes
• Monitoring error logs while debugging a production issue
• Running periodic linting or type-checking during a refactor

If you need the task to survive a terminal restart, keep reading.

/schedule — Persistent Scheduled Tasks

The /schedule command creates durable tasks that persist across sessions. This is Claude Code's answer to cron — but with full access to the agent's capabilities.

Two Flavors: Desktop and Cloud

Desktop scheduled tasks run on your local machine. They have full access to your filesystem, MCP servers, skills, and local tools. The trade-off: your machine needs to be on and Claude Code's desktop app (Cowork) needs to be running.

Cloud scheduled tasks run on Anthropic's infrastructure. They don't need your machine at all — they execute in a cloud environment with network access and configurable environment variables. The trade-off: no local file access.

Creating a Scheduled Task

You have three entry points:

1. CLI conversational setup:

/schedule

Claude walks you through the configuration interactively — what to run, when, and where.

2. CLI one-liner:

/schedule daily PR review at 9am

Claude infers the schedule from natural language and sets it up.

3. Web interface: Visit claude.ai/code/scheduled to create and manage tasks through a form-based UI. This is the easiest way to see all your scheduled tasks at a glance.

Scheduling Options

The default schedule is daily at 9:00 AM in your local time zone. For custom schedules, you can use natural language or standard five-field cron expressions:

# Every weekday at 9 AM
0 9 * * 1-5

# Every 2 hours during business hours
0 9-17/2 * * 1-5

# Every Monday at 8:30 AM
30 8 * * 1

The minimum interval for scheduled tasks is 1 hour. If you need something more frequent, use /loop instead.

Timing note: The scheduler adds a small deterministic jitter to fire times to distribute load. If exact-minute precision matters, avoid scheduling on round numbers like :00 or :30 — use something like 3 9 * * * instead of 0 9 * * *.

Real-World Scheduled Task Examples

Daily PR summary:

/schedule
> Every weekday at 9am, review all open PRs in this repository. 
> Summarize what changed, flag any potential issues, and post 
> a summary to the #dev-updates Slack channel.

Weekly dependency audit:

/schedule
> Every Monday at 8am, check all dependencies for known 
> vulnerabilities, outdated packages, and license issues.
> Create a GitHub issue with the findings.

Nightly test suite:

/schedule
> Every night at 2am, run the full test suite and report 
> any failures. If tests fail, create a draft PR with fixes 
> for straightforward issues.

Managing Scheduled Tasks

View all your scheduled tasks:

/schedule list

From the web interface at claude.ai/code/scheduled, you can pause, edit, delete, and view execution history for all tasks.

Headless Mode + System Cron — Maximum Control

For developers who want full control over scheduling infrastructure, Claude Code's headless mode (-p flag) turns it into a single-shot command-line tool that's perfect for wrapping in system-level schedulers.

How Headless Mode Works

claude -p "Summarize the latest PRs in this repo"

The -p (or --print) flag runs Claude Code non-interactively: it processes one prompt, outputs the result, and exits. No session UI, no conversation state — just input and output.

This makes it a clean target for cron, systemd timers, or any scheduler that can execute shell commands.

Setting Up a Cron Job

Edit your crontab:

crontab -e

Add a scheduled task:

# Every weekday at 9 AM — review open PRs
0 9 * * 1-5 cd /path/to/repo && claude -p "Review open PRs and summarize findings" >> /var/log/claude-review.log 2>&1

# Every 6 hours — check error logs
0 */6 * * * cd /path/to/project && claude -p "Check the last 6 hours of error logs and flag anything critical" >> /var/log/claude-errors.log 2>&1

# Every Sunday at midnight — weekly code quality report
0 0 * * 0 cd /path/to/repo && claude -p "Generate a weekly code quality report covering test coverage, linting issues, and technical debt" >> /var/log/claude-quality.log 2>&1

Session Continuity Across Invocations

By default, each headless invocation starts a fresh session. But you can chain invocations together using session IDs:

# First invocation — capture session ID from JSON output
SESSION_ID=$(claude -p "Start analyzing the codebase for performance issues" --output-format json | jq -r '.session_id')

# Follow-up invocation — continue the same session
claude -p "Continue the analysis and focus on database queries" --session-id "$SESSION_ID"

This lets you build multi-step workflows where each cron invocation builds on the previous one's context.

Using systemd Timers Instead of Cron

For more robust scheduling on Linux, systemd timers provide better logging, dependency management, and failure handling:

# /etc/systemd/system/claude-review.service
[Unit]
Description=Claude Code PR Review

[Service]
Type=oneshot
WorkingDirectory=/path/to/repo
ExecStart=/usr/local/bin/claude -p "Review open PRs and post summary"
User=developer

# /etc/systemd/system/claude-review.timer
[Unit]
Description=Run Claude PR review daily

[Timer]
OnCalendar=Mon-Fri 09:00
Persistent=true

[Install]
WantedBy=timers.target

Enable with:

sudo systemctl enable --now claude-review.timer

When to Use Headless + Cron

This approach gives you maximum control but requires more setup. It's best for:

• Teams with existing infrastructure automation
• Workflows that need to pipe Claude's output into other tools
• Environments where you can't use Anthropic's cloud scheduler
• Multi-step workflows with custom orchestration logic

GitHub Actions — CI/CD Scheduling

Anthropic ships an official GitHub Action — anthropics/claude-code-action@v1 — that brings Claude Code into your CI/CD pipelines. Combined with GitHub's schedule trigger, this creates powerful automated workflows that run on GitHub's infrastructure.

Setup

Run /install-github-app in any Claude Code CLI session to install the GitHub app and configure the required secrets for your repository.

Scheduled Workflow Examples

Daily security audit:

name: Daily Security Audit
on:
  schedule:
    - cron: '0 9 * * 1-5'

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Audit this repository for security issues:
            1. Check dependencies for known vulnerabilities
            2. Scan for hardcoded secrets or credentials
            3. Review recent changes for security anti-patterns
            Create an issue with your findings.

Weekly release notes:

name: Weekly Release Notes
on:
  schedule:
    - cron: '0 10 * * 1'

jobs:
  release-notes:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Generate release notes for all commits since last Monday.
            Group changes by category (features, fixes, docs, chores).
            Post the summary as a GitHub release draft.

On-demand via PR mentions:

Beyond scheduling, the GitHub Action also supports triggering Claude by mentioning @claude in any PR or issue comment. This gives your team on-demand access to Claude's analysis without leaving GitHub.

When to Use GitHub Actions

• Your team needs scheduled automation without managing infrastructure
• Workflows that should run in a clean CI environment
• Tasks that integrate with GitHub's ecosystem (issues, PRs, releases)
• Team-wide automation where multiple people need visibility

Choosing the Right Scheduling Method

Here's a decision framework based on common scenarios:

Prompt Design for Scheduled Tasks

Scheduled tasks run without human oversight, which changes how you should write prompts. A prompt that works great interactively might fail silently as a scheduled task because there's no one to answer clarifying questions.

Rules for scheduled prompts:

1. Be completely self-contained. Define exactly what to check, where to look, and what to do with the results.
2. Define success and failure clearly. "Check the deployment" is vague. "Check if the staging deployment at staging.example.com returns a 200 status on /health" is actionable.
3. Specify output handling. Should results go to Slack? A GitHub issue? A log file? An email? Tell Claude explicitly.
4. Handle the "nothing to report" case. Should Claude skip posting if everything is fine, or confirm that things are healthy? Either is valid — just be explicit.
5. Set boundaries. If Claude finds a failing test, should it attempt a fix? Or just report? Define the scope of autonomous action you're comfortable with.

Example of a well-structured scheduled prompt:

Review all PRs opened in the last 24 hours in this repository.
For each PR:
- Summarize the changes in 2-3 sentences
- Flag any potential security issues, performance regressions, or breaking changes
- Note if tests are missing for new functionality

If there are no new PRs, do nothing.
If there are findings, post a summary as a comment on each PR.

Combining Methods for Multi-Layer Automation

The scheduling methods aren't mutually exclusive. Advanced setups layer them together:

• Cloud /schedule runs a nightly code quality scan and files GitHub issues for anything it finds
• GitHub Actions picks up those issues and triggers Claude to attempt automated fixes as PRs
• /loop monitors the resulting CI runs during your morning session and alerts you to failures

Each tier handles what it's best at: cloud for durability, Actions for CI integration, and /loop for real-time awareness during active work.

Key Takeaways

• /loop is for quick, session-scoped polling — monitoring deployments, watching CI, periodic checks during active work. It dies when you close the terminal.
• /schedule creates persistent tasks that survive restarts. Use cloud tasks for always-on automation, desktop tasks for workflows needing local access.
• Headless mode (claude -p) turns Claude Code into a cron-friendly CLI tool for maximum scheduling control and custom orchestration.
• GitHub Actions with anthropics/claude-code-action@v1 bring scheduled Claude workflows into your CI/CD pipeline with team-wide visibility.
• Prompt quality matters more for scheduled tasks because there's no human in the loop to clarify. Make prompts self-contained, specific, and explicit about output handling.
• Layer methods together for comprehensive automation — use each tier for what it does best.