/loop is the most misunderstood scheduling feature in Claude Code, and the misunderstanding is baked into how people describe it: "cron inside your IDE." It is not cron, and treating it like cron will eventually cost you a missed job that mattered. I feel entitled to be picky about this because I run both: /loop daily during development, and real schedulers in production, including a sitemap job that has fired every five minutes on my Laravel site for months. The honest boundary between those two worlds is the thing this post is actually about.
What /loop Is
The mechanics are simple. Inside a Claude Code session:
/loop 5m /check-deploy
That reruns a prompt or slash command on an interval: every five minutes, run my deploy check. Omit the interval and the model self-paces, deciding when the next iteration is worth running, which sounds like a gimmick and turns out to be the better mode for anything where "check again" only makes sense after something else finished.
The crucial property: the loop lives inside your session. It is not registered with the operating system. There is no daemon. Claude is, in effect, agreeing to keep doing something on a schedule for as long as the session exists.
What /loop Is Genuinely Good At
The category it owns is watch-and-react work during active development. The difference between /loop and crontab is that a cron job runs a command, while a loop iteration runs a model with tools and judgment. My real uses:
CI babysitting. /loop 5m on "check the latest GitHub Actions run with gh run list; if it failed, pull the log and diagnose." My deploys go through Actions to production, and gh run list sits permanently in my permission allowlist because of exactly this pattern. The loop does not just tell me the build failed; it reads why and has a diagnosis waiting.
Test-until-green. During a gnarly refactor: loop on "run the affected PHPUnit suite; if anything fails, show me the first failure only." Self-paced mode shines here, because rerunning on a timer while I am mid-edit is noise.
Queue and log watching. "Every 10 minutes, tail the Laravel log for new errors and summarize anything unusual." A cron job can grep a log. It cannot tell you that the new error is probably related to the migration you ran an hour ago.
That judgment-per-iteration is the actual feature. If the recurring task needs zero judgment, a shell script in a while-loop is cheaper.
The Session Boundary, and Why I Refuse to Pretend It Away
Close the laptop, kill the terminal, lose the connection: the loop dies with the session. No catch-up run, no alert. This is not a flaw to be patched; it is the design, and it defines what /loop must never be trusted with.
I have a production story that makes this concrete. My site's scheduler runs generate:sitemap every five minutes and a queue worker every minute, with withoutOverlapping guards, via a single crontab entry on Hostinger. In June 2026 that crontab entry simply vanished. Queues silently stopped; scheduled emails piled up unsent. What got it caught and fixed was boring production discipline: external checks, idempotent jobs, and guards that made the recovery safe to rerun.
Now imagine that responsibility living in a /loop inside a terminal on my Mac. Every lid-close would be an outage. The lesson generalizes into a rule I now apply mechanically: if a missed iteration has a cost, it does not belong in /loop.
Choosing the Right Scheduler: The Three-Tier Decision
There are three tiers, and each has a legitimate territory:
| Tier | Survives your laptop? | Has judgment? | Use for |
|---|---|---|---|
/loop (in-session) |
No | Yes | Dev-time watching: CI, tests, logs, long jobs |
Scheduled cloud routines (/schedule) |
Yes | Yes | Recurring agent work: daily audits, reports, content checks |
| crontab / Laravel scheduler | Yes | No | Production machinery: sitemaps, queues, backups |
The middle tier is the newest and covers the gap: agent tasks that must run whether or not you are at the keyboard. I moved my recurring SEO regression checks there, which I documented in automating SEO checks with Claude Code routines, and the broader platform side in Claude routines as an automation platform. The same scheduled-task concept exists on the Cowork side too, covered in Claude Cowork scheduled tasks.
The bottom tier should stay dumb on purpose. My sitemap cron does not need a model; it needs to fire every five minutes forever, with withoutOverlapping so a slow run never stacks. Judgment in production scheduling is a liability where repeatability is the requirement.
Context Rot: The Cost Nobody Mentions Up Front
A loop iterating for hours accumulates context. Every iteration's output stays in the session, and by iteration thirty the model is carrying a transcript of twenty-nine mostly-identical status checks. Two symptoms appear: responses slow down, and, more subtly, the model starts pattern-matching against previous iterations instead of looking freshly ("still passing" when it stopped passing).
My mitigations, learned the mildly annoying way:
- Make each iteration output a verdict, not a report. "PASS" or one line of failure. Small outputs rot slowly.
- Loop on commands, not prose.
/loop 10m /lint-checkkeeps iterations uniform and cheap; freeform prompts drift. - Restart long loops. For anything running beyond a couple of hours, kill the session and start clean. Keep the loop command in a notes file so recreating it costs five seconds.
Setting Up Your First Useful Loop
Skip the toy examples. Day one, do this:
- Pick the thing you manually check most often during work. For most developers that is CI status or a failing test suite.
- Write the check as a single slash command or one-sentence prompt with an explicit output format ("reply PASS or the first error only").
/loop 10m <your check>. Ten minutes, not one; aggressive intervals mostly buy you context rot.- When the session ends, let it die. If you catch yourself wishing it survived, that wish is your signal: promote it to a scheduled routine or real cron, per the table above.
/loop sits alongside a handful of other quietly powerful features (hooks, background tasks, permission allowlists) that most people never find; I collected those in Claude Code hidden features worth using.
I build this kind of layered automation professionally: dev-time loops for the team, cloud routines for the recurring agent work, and boring, guarded cron for production, with monitoring so nothing fails silently. If your team's scheduling story is currently "someone remembers to check," my services cover designing and installing one that does not depend on memory.
