Claude Code: Loop Automation

Last week I was babysitting a staging deployment — refreshing the terminal every few minutes like some kind of anxious intern. Sound familiar? I'm Dora, a principal-level engineer who's been running AI coding tools through their paces on real production workflows, and the moment I found the claude code loop command, I realized I'd been wasting my own time on exactly the kind of polling work a machine should do.

This guide is what I wish I'd had before I started: no fluff, just the mechanics, real use cases I've personally tested, and a straight answer on when /loop is genuinely enough vs. when you need something more durable.

What /loop Actually Does

/loop is a bundled skill in Claude Code that lets you schedule a recurring prompt to fire automatically in the background — without you typing it again. You pass it an interval and a task description, and Claude converts that into a cron expression, schedules the job, and confirms the cadence plus a job ID.

Think of it as telling Claude: "every 5 minutes, go check if that deployment finished and tell me what happened" — and then actually walking away.

Tasks fire in the background while your session stays open. They're designed for things like polling a build, watching a PR, scanning error logs, or setting a timed reminder to push a branch. They're not a replacement for CI/CD pipelines or persistent cron infrastructure.

Prerequisites

Before typing your first /loop command:

• Claude Code installed and authenticated (claude --version to verify)
• An active Claude session open in your terminal
• The CLAUDE_CODE_DISABLE_CRON environment variable must not be set to 1 — if it is, the scheduler is disabled entirely and /loop becomes unavailable

That's it. No external services, no config files to edit.

Basic Syntax

/loop [interval] [prompt]

Example:

/loop 5m check if the deployment finished and tell me what happened

Claude parses the interval, converts it to a cron expression, schedules the job, and confirms the cadence and job ID back to you.

Time Units

Default Interval

Interval is optional. If you omit it, /loop defaults to every 10 minutes.

/loop check git status and summarize any new commits

Natural Language Syntax

For one-shot reminders, skip the /loop prefix and just describe what you want in plain English:

remind me at 3 PM to push the release branch

Claude schedules a single-fire task that automatically deletes itself after running. It pins the fire time to a specific minute and hour using a cron expression and confirms when it will fire.

Nested Commands

The scheduled prompt can itself be a slash command or skill invocation. This is useful for re-running a workflow you've already packaged:

/loop 30m /review-pr 1234

Each time the job fires, Claude runs /review-pr 1234 as if you typed it yourself.

5 Real Use Cases

Watching a Deployment

This is the use case that sold me. Instead of refreshing the terminal:

/loop 5m check if the staging deployment at port 3000 is responding, 
and tell me the HTTP status code

Claude polls every 5 minutes and surfaces the result without you lifting a finger. When the deployment goes live, you'll know within the next interval.

Auto PR Review

Set a watch on an open PR and get notified when CI status changes:

/loop 10m /review-pr 1234

Claude re-runs your existing review skill every 10 minutes. Combine this with a notification in your prompt ("if CI is failing, tell me loudly") and you've got passive PR oversight.

Daily Team Digest

Useful for async teams working across time zones. Run this at the start of your session:

/loop 1d summarize all commits from the last 24 hours across the main branch, 
group by author, and flag anything that touches the payments module

Claude generates a digest every 24 hours while your session is open. For teams that want this to survive restarts, this is a signal to move to GitHub Actions (more on that below).

One-Time Timed Reminder

Don't let a release step fall through the cracks:

remind me at 4:45 PM to tag the release candidate before the deploy window closes

Single-fire, self-deleting. No cleanup needed.

Error Log Scanning

Spotted by Anthropic developer Thariq Shihipar as a showcase use case:

/loop 2h scan the error logs in ./logs/app.log for new FATAL entries 
since the last check. If any are fixable, open a PR with the fix.

Claude checks logs every 2 hours and — when connected to your repo tools — can actually create the PR. This is where /loop starts feeling genuinely autonomous rather than just scheduled.

Under the Hood

The /loop skill is a user-facing shorthand. Underneath it, Claude uses three native tools you can also call directly:

CronCreate

Creates a scheduled task. Claude internally generates a standard POSIX cron expression — for example, */5 * * * * for every 5 minutes — and registers the job with an 8-character ID.

Jitter behavior to be aware of: To avoid all sessions hitting 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 might fire anywhere from :00 to :06)
• One-shot tasks scheduled for the top or bottom of the hour fire up to 90 seconds early

If exact timing matters — for a release window, say — pick a minute that isn't :00 or :30. Use 3 9 * * * instead of 0 9 * * * and the one-shot jitter won't apply.

CronList

Lists all active tasks in the current session with their IDs, expressions, and prompts. Ask Claude naturally:

what scheduled tasks are currently running?

CronDelete

Cancels a task by ID. Again, just ask naturally:

cancel the deployment watcher

Or reference the job ID directly if you have it from the confirmation message.

Limitations You'll Actually Hit

I want to be direct here — these aren't edge cases, they're real constraints that matter for production thinking.

Session-Scoped

Tasks only live while Claude Code is running and idle. Close the terminal, exit the session, lose your SSH connection — every task is gone. No recovery. This is the constraint that matters most for anything mission-critical.

3-Day Expiry

Recurring tasks automatically expire 3 days after creation. The task fires one final time, then deletes itself. This bounds how long a forgotten loop can run, which is good hygiene — but it means you can't set a /loop task and walk away for a week.

50-Task Cap

A session can hold a maximum of 50 scheduled tasks. For most individual workflows this is plenty. If you're building something more elaborate, count your tasks.

No Catch-Up Runs

If a task's scheduled time passes while Claude is busy on a long-running request, it fires once when Claude becomes idle — not once per missed interval. So if you have a 5-minute loop and Claude spends 20 minutes on a heavy refactor, you get one fire after it finishes, not four.

Here's the full picture in one table:

When /loop Is Enough vs When It's Not

This is the question I get asked most. Here's how I think about it:

/loop is enough when:

• You need polling or reminders within an active working session
• The task duration is hours, not days
• You're fine with manual restart if you close Claude Code
• It's a personal workflow, not a team dependency

/loop is not enough when:

• You need tasks to survive restarts or run overnight unattended
• The automation is team-critical (CI gates, deployment checks, alerts)
• You need guaranteed timing (financial operations, release windows)
• You're on Linux and want persistent scheduling (Desktop scheduled tasks are macOS/Windows only)

For those cases, the right tools are:

• GitHub Actions with a schedule: trigger using POSIX cron syntax — runs unattended in CI without a local terminal. GitHub's minimum interval is 5 minutes, and as their docs note, scheduled runs can be delayed during high-load periods (top of the hour is the worst time to schedule)
• anthropics/claude-code-action — the official GitHub Action for running Claude Code tasks inside workflows, including scheduled runs, with support for Anthropic API, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry

• Claude Code Desktop scheduled tasks (macOS and Windows) — persistent GUI-based scheduling that survives restarts and supports Git worktree isolation per run
• claude -p in headless mode piped into your system's own crontab — gives you full control with existing infrastructure

# GitHub Actions example for durable scheduling
# Uses anthropics/claude-code-action@v1 (official GA release)
name: Claude Code Scheduled
on:
  schedule:
    - cron: '3 9 * * 1-5'  # Weekdays at 9:03 AM UTC — avoid :00 to reduce queue delay
  workflow_dispatch:
jobs:
  claude-automation:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          prompt: "Review yesterday's commits and summarize in an Issue"
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

Verdict

The claude code loop command solves a real problem: it removes the cognitive overhead of manually re-running checks during an active dev session. For deployment watching, log scanning, PR polling, and timed reminders, it's genuinely useful and takes 10 seconds to set up.

But it's explicitly session-scoped — and that's not a bug, it's the design. Anthropic built Desktop scheduled tasks and Claude Code GitHub Actions integration for the persistent, team-critical automation layer. Think of /loop as your in-session copilot, not your overnight cron daemon.

If you're already in Claude Code and need something to run while you work, start with /loop. When you need it to outlast your terminal session, reach for GitHub Actions or Desktop scheduled tasks.

You might also find these useful:

Claude Max 20x: Open Source Offer

Claude Code: Remote Control Setup

Claude Code: Worktree Setup

Claude Code Security: Production Readiness

Claude Sonnet 4.6: Writing Collaborator