Claude Code /loop: Run Recurring Tasks on Autopilot
Claude Code keeps shipping features that blur the line between coding assistant and development infrastructure. The latest one that changed how I work is /loop - a session-scoped scheduler that lets you run any prompt or command on a recurring interval, right inside your terminal.
If you have ever left a terminal tab open just to keep checking whether a build passed, a deploy went through, or a PR got approved - this is the feature you did not know you needed.
What /loop Actually Does
The /loop command schedules a recurring prompt inside your active Claude Code session. You give it an interval and a task, and Claude fires that prompt automatically in the background while you keep working.
Noah Zweben, who works on Claude Code at Anthropic, shared the feature with a simple example: /loop 5m make sure this PR passes CI. That one line sets up a recurring check every five minutes. No cron tab. No separate monitoring tool. Just Claude watching your CI pipeline while you move on to the next thing.
Syntax and Defaults
The syntax is deliberately simple. You can put the interval at the beginning, the end, or leave it out entirely.
Leading interval: /loop 5m check if the deployment finished
Trailing interval: /loop check the build every 2 hours
No interval: /loop check the build (defaults to every 10 minutes)
Supported units are s for seconds, m for minutes, h for hours, and d for days. You can also loop over other Claude Code commands. For example: /loop 20m /review-pr 1234 runs a PR review every 20 minutes. Any slash command or skill can be the target.
How Long Do Loops Run?
Recurring tasks now run for up to 7 days before auto-expiring. The task fires one final time, then deletes itself. This is a safety bound - it prevents a forgotten loop from running indefinitely and burning through API credits.
If you need something to run longer, you can cancel and recreate the loop before it expires. For truly durable scheduling that survives restarts and runs without an active terminal, Claude Code also supports Desktop scheduled tasks and GitHub Actions workflows with schedule triggers.
How It Differs from Cron Jobs
On paper, /loop sounds like cron. But the key difference is context.
A traditional cron job runs a script in isolation. It has no awareness of your codebase, your current branch, your open PRs, or what you were working on five minutes ago. It executes blindly.
/loop runs inside an active Claude Code session. That means Claude has full access to your project context, your file tree, your git history, and every tool available in the session - including MCP servers, bash, file editing, and web search. When Claude checks your CI status, it can actually read the error logs, identify the problem, and propose or even apply a fix.
The other practical difference is setup time. A cron job requires writing a script, configuring the schedule, handling logging, and managing permissions. A loop is one line typed into your terminal.
Practical Use Cases
Here are the workflows where /loop delivers the most value:
Monitor CI/CD builds. /loop 5m check if the CI build passed and summarize any failures. Instead of refreshing GitHub Actions every few minutes, let Claude watch it and tell you when something needs attention.
Watch for PR updates. /loop 15m check PR #42 for new comments or review requests. Especially useful when you are waiting on a review and want to respond quickly without keeping the tab open.
Poll deployment status. /loop 3m check the Vercel deployment status for the latest commit. I use a version of this when I push to my dev environment. Claude checks the deploy, confirms it went live, and flags any build errors.
Run periodic code quality checks. /loop 1h run the linter on changed files and report any new warnings. Good for long coding sessions where lint issues can pile up.
Check server health. /loop 10m curl the health endpoint and let me know if anything looks wrong. Lightweight uptime monitoring without leaving your editor.
Monitor error rates. /loop 30m check the error logs for the last 30 minutes and summarize any new patterns. Useful during and after a release when you want to catch regressions early.
Babysit webhook integrations. This is one I use regularly. After updating my Shopify webhook handler, I run /loop 5m check the webhook logs for any failed deliveries to make sure everything is processing correctly. It has caught issues that would have taken me hours to notice otherwise.
Tips for Effective Loops
Keep the prompt focused. A loop prompt should do one thing well. "Check the deploy" is better than "check the deploy, review the logs, update the changelog, and notify Slack." If you need multiple checks, create multiple loops.
Choose appropriate intervals. A CI build does not need checking every 30 seconds. Match the interval to the expected pace of the thing you are watching. 3-5 minutes for active deploys, 15-30 minutes for PR reviews, 1 hour for code quality sweeps.
Remember it is session-scoped. Closing your terminal kills all loops. If you are relying on a loop for something important, keep the session alive. For anything that needs to survive a restart, use Desktop scheduled tasks or GitHub Actions instead.
Combine with other tools. The real power of /loop comes from combining it with everything else Claude Code can do. A loop that checks your deploy can also read error logs, search your codebase for the root cause, and draft a fix - all in one firing.
My Setup
I run RAXXO Studios as a one-person operation - a Next.js SaaS app, a Shopify store with over 100 products, and a content pipeline. That means I am deploying, monitoring, and debugging across multiple systems simultaneously.
My most-used loop is a simple Vercel deploy watcher: /loop 3m check the latest Vercel deployment and tell me if it succeeded or failed. I kick it off after pushing to my dev environment and forget about it. Claude pings me when it is done or when something breaks.
The second most common is webhook monitoring after I change any API endpoint. Shopify webhooks can fail silently, and a 5-minute loop checking delivery status has saved me from shipping broken integrations to production more than once.
/loop is not a replacement for proper monitoring infrastructure. But for a solo developer who needs to keep multiple plates spinning, it is the fastest way to add a set of eyes on something without leaving your terminal.
This article contains affiliate links. If you sign up through them, I earn a small commission at no extra cost to you.
This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)
Back to all articles
