As an indie developer juggling several small apps, between sessions I kept wishing the late-night chores — reviewing pull requests, watching an error log — could happen while I slept. But standing up a server cron just for that, and then babysitting it, felt like too much. So when Claude Code added the /loop command, I pointed it straight at that "light, always-on" work and ran it for a few weeks.
The short version: the convenience was everything I'd hoped for, but if you treat it like a plain cron, a few habits will trip you up. Below is the basic usage, plus the gotchas I only understood after getting burned, and where I ended up drawing the line between what /loop should handle and what belongs elsewhere.
The basics — schedule a repeat in one line
/loop runs any prompt or slash command on a fixed interval. The syntax is just an interval followed by what to run.
/loop [interval] [prompt or command]
To review a specific pull request every two hours, for instance:
/loop 2h /review-pr 1234
As long as the session stays open, PR #1234 gets reviewed automatically every two hours. Intervals use the units below, and if cron syntax isn't your thing, you can describe the interval in plain language and Claude will interpret it.
| Unit | Notation | Example |
|---|---|---|
| Seconds | s | 30s |
| Minutes | m | 15m |
| Hours | h | 2h |
| Days | d | 1d |
The first two I set up were log monitoring and tests.
/loop 15m Check logs/error.log and report only the key points of any critical errors
/loop 30m Run the test suite, and if anything fails, investigate the cause and fix it
Catch log anomalies every 15 minutes, run tests every 30. Without anyone watching, by morning the conversation had a running record of what broke and what got fixed. That part was exactly as pleasant as I'd imagined.
Three quirks I only learned by using it
The trouble showed up when I trusted it the way I'd trust a plain cron. I'd read the docs and thought I understood these three points — but I only really learned them after dropping the ball.
Close the session and everything disappears
/loop tasks fire only while Claude Code is running and idle. Close the terminal or end the session, and every registered task is cancelled together. Once, I shut my laptop and headed out, and came home to find nothing had run at all. Unlike a cron on a server, it doesn't keep going once you walk away from the machine. If you want it resident, you have to plan around keeping the terminal open and the machine awake.
Tasks auto-expire after 3 days
Each task has a three-day lifespan from creation. After firing one last time, it quietly deletes itself. If you assume "set it once and it runs forever," you'll be puzzled when the task is simply gone the following week. It's a poor fit for anything you want running permanently. Treat it as a tool for lightening the work of these particular few days, and it fits.
It only fires when idle
When Claude Code is busy with other work, scheduled tasks wait for a gap. While I was deep in an interactive implementation, that 15-minute log check did not arrive neatly every 15 minutes. For anything that needs a strict clock — "aggregate at the top of every hour, no exceptions" — it's safer to look elsewhere.
Deciding between /loop and a real cron
Once those quirks sink in, /loop's sweet spot comes into focus. I settled on this split.
- Work that wraps up in a few days and only needs to happen while I'm around → hand it to
/loop(PR previews, skimming logs, a light check on work-in-progress code) - Work that must keep running after I close the terminal → move it to a server cron / CI
- Work that must honor an exact schedule → avoid
/loop(idle-waiting causes drift) - Failures that must reliably reach a human → put monitoring on a separate track (if the session dies,
/looptakes the alerting down with it)
Put another way, /loop isn't a CI/CD replacement — it's a companion that handles odd jobs alongside an interactive session. Get that line right, and the small daily repetitions get noticeably lighter.
One more thing: you'll often want to tell whether a scheduled task has stalled or is simply waiting its turn. I've written separately about diagnosing a Claude that won't respond in How to tell when Claude stops responding — and what to do, which pairs well with this.
Your next step
If you want to try it, don't hand it real work right away. Start with a harmless read-only task — something like watching logs/error.log, where a miss breaks nothing. A few days in, the idle-wait drift and the three-day disappearance become things you know in your bones. From there, lift only the "keep going after I close the terminal" pieces up to a server, and the division of labor between /loop and server cron settles itself.
I started out expecting this one tool to cover all my overnight work, and I dropped plenty. I'm writing down the stumbles in the order I hit them, in the hope it spares someone the same detour.