Claude Code /loop: Poll a Deploy, Babysit a PR, and Get Told When It's Done

You kicked off a deploy, or opened a pull request, or started a build that takes twenty minutes. Now you are sitting in Claude Code typing "check again" every few minutes like a human cron job. The /loop skill exists so you can stop doing that: it re-runs a prompt on a schedule, inside the session, until the thing you are waiting for happens or you cancel it.

This guide covers how /loop works in practice, the three ways to use it, the rules that trip people up (jitter, the seven-day expiry, what survives a restart), and how to pair it with a notification so you find out when the loop has done its job instead of watching it.

What /loop actually does

/loop is a bundled skill that schedules a prompt to run repeatedly in the current session. Under the hood it uses Claude Code's scheduling tools (CronCreate, CronList, CronDelete), which accept a standard five-field cron expression and a prompt. The scheduler checks every second for due tasks and fires them between your turns, never in the middle of a response. If Claude is busy when a task comes due, the prompt waits until the current turn ends.

That last detail matters: a loop is not a separate process. It is the same session, re-prompted. It has your context, your permissions, and your MCP servers. It also stops firing the moment the session exits, which is both the main limitation and the reason it is so cheap to set up.

Three ways to run it

1. Fixed interval: you choose the cadence

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

Give an interval and a prompt, and Claude converts the interval to a cron expression and confirms the cadence and job ID. The interval can lead the prompt as a bare token (30m) or trail it as a clause (every 2 hours). Units are s, m, h and d. Seconds round up to the next minute, and intervals that do not map to a clean cron step, such as 7m or 90m, are rounded to the nearest one that does; Claude tells you what it picked.

2. Self-paced: Claude chooses the interval

/loop check whether CI passed and address any review comments

Omit the interval and Claude picks a delay after each iteration, between one minute and one hour, based on what it saw: short waits while a build is finishing or a PR is active, longer waits once things go quiet. The chosen delay and the reason are printed at the end of every iteration. This is the mode to reach for when you do not know how long the wait will be, which is most of the time.

In sessions where the Monitor tool is available, Claude may use it instead of re-prompting: Monitor runs a background script and streams each output line back, which avoids polling altogether and is usually cheaper in tokens.

3. Bare /loop: the built-in maintenance prompt

/loop
/loop 15m

With no prompt at all, Claude runs a built-in maintenance prompt: it continues unfinished work from the conversation, tends to the current branch's pull request (review comments, failed CI runs, merge conflicts), and runs cleanup passes such as bug hunts when nothing else is pending. It does not start new initiatives, and irreversible actions like pushing or deleting only proceed when they continue something the transcript already authorised. Add an interval to run it on a fixed schedule instead of a self-paced one.

You can replace that default with your own instructions in a loop.md file: .claude/loop.md for a project, or ~/.claude/loop.md for everything. Claude uses the first one it finds, project first, and ignores the file whenever you pass a prompt on the command line. Edits take effect on the next iteration, so you can tune a running loop. Content beyond 25,000 bytes is truncated.

Loops can run skills, with limits

/loop 20m /review-pr 1234 re-runs a skill each iteration. A scheduled fire only runs skills Claude is allowed to invoke on its own. Built-in commands such as /permissions or /clear, skills marked disable-model-invocation: true (including the bundled /verify), skills withheld by a skillOverrides setting or a Skill deny rule, and MCP prompts all reach Claude as plain text instead of executing. If a loop seems to be "ignoring" a skill, that is almost always why.

One-time reminders without /loop

For a single future check you do not need the skill at all. Ask in plain language:

remind me at 3pm to push the release branch
in 45 minutes, check whether the integration tests passed

Claude schedules a one-shot task pinned to a specific minute and hour and confirms when it will fire. The task deletes itself after running.

The rules that surprise people

• Jitter. To stop every session hitting the API at the same wall-clock moment, recurring tasks fire up to 30 minutes after the scheduled time (or up to half the interval for tasks more frequent than hourly). An hourly job set for :00 can fire anywhere up to :30. One-shot tasks on the top or bottom of the hour fire up to 90 seconds early. The offset is derived from the task ID, so it is stable. If timing matters, pick a minute that is not :00 or :30, for example 3 9 * * *.
• Seven-day expiry. Recurring tasks expire seven days after creation: they fire one final time, then delete themselves. This bounds how long a forgotten loop can run. Cancel and recreate it if you need longer, or move to a durable scheduler (below).
• No catch-up. If a scheduled time passes while Claude is busy on a long request, the task fires once when Claude is idle, not once per missed interval.
• Local time. Cron expressions are interpreted in your local timezone, not UTC.
• Fifty tasks per session. Each has an 8-character ID you can pass to CronDelete.
• Extended cron syntax is not supported. Wildcards, steps, ranges and lists work; L, W, ? and name aliases like MON do not.

What survives a restart, and what does not

Tasks are session-scoped, so closing the terminal or letting the session exit stops them. When you resume with claude --resume or --continue, Claude Code restores tasks created with CronCreate, minus recurring tasks that have expired and one-shots whose time has passed. A self-paced /loop is not restored; run it again. Background Bash and Monitor tasks are never restored on resume.

If you background the whole session instead of exiting it, the loop carries over to the background session and keeps running without a terminal. That is the cleanest way to keep a loop alive overnight on your own machine. For something that should run whether or not your laptop is open, Claude Code points you at Routines (cloud, minimum interval one hour, runs autonomously in a fresh clone), Desktop scheduled tasks (your machine, access to local files, minimum interval one minute), or a GitHub Actions schedule trigger.

Stopping a loop

For a self-paced loop that is waiting for its next iteration, press Esc: it clears the pending wakeup so the loop does not fire again. Claude can also end a self-paced loop itself once the task is complete, and if an iteration ends without rescheduling or stopping, Claude Code schedules one fallback wakeup about 20 minutes later and ends the loop when that one does not reschedule either.

Fixed-interval loops and tasks you created by asking Claude directly are not affected by Esc. List them with "what scheduled tasks do I have?" and cancel with "cancel the deploy check job", or by ID. To switch the scheduler off entirely, set CLAUDE_CODE_DISABLE_CRON=1; the cron tools and /loop then become unavailable and already-scheduled tasks stop firing.

The missing piece: knowing when the loop is done

A loop that polls your deploy every five minutes is only useful if you are not also polling the terminal every five minutes. Two things close that gap. First, write the prompt so the loop produces a clear terminal state: "when the deployment status is Succeeded or Failed, say so in one line and stop the loop." Second, make that final response trigger a notification you will actually notice.

Every iteration of a loop ends with Claude finishing a response, which fires Claude Code's Stop hook, so the same setup from our notifications guide works unchanged. If you only want to hear about the final iteration, tell the loop to end with a distinctive phrase and filter on it in your hook, or simply accept one quiet ping per iteration and a louder one at the end. Loops that run while you are away from the desk pair well with phone notifications, and the Remote Control app lets you read the loop's last message from your phone and cancel it if the deploy went sideways.

A sensible starter workflow

1. Start the long thing: a deploy, a CI run, a migration.
2. Run a self-paced loop with an explicit stop condition: /loop check the deploy status; when it is Succeeded or Failed, report it in one line and stop.
3. Make sure a Stop notification is in place, then go do something else.
4. When the ping arrives, read the one-line result. If the loop is still running for some reason, Esc or "cancel the deploy check" ends it.

That is the whole trick: let Claude do the polling, let the notification do the watching, and keep your own attention for the work that needs it.