Claude Code Scheduled Tasks: Automate Recurring Workflows

Every Monday morning, for about two years, I did the same thing. Open the laptop, run npm audit, skim the output, grep the changelog, check which PRs merged on Friday, count the sprint tickets that slid, pour a second coffee.

This was my ritual. A small, repetitive pilgrimage I performed before I was allowed to do real work. And I hated it. Not because it was hard, but because it was obviously a machine's job that I kept insisting on doing by hand.

Then Claude Code Scheduled Tasks shipped. And the ritual died. Or rather, claude code scheduled tasks moved the ritual from me to a well-instructed agent running on Anthropic's cloud while I slept. Same checklist, different pilot.

What I want to share in this post are the five claude code scheduled tasks currently running in my background, the exact commands I used to set them up, and the one rule I follow before I schedule anything: would a personal assistant with a checklist do this better than me? If the answer is yes, I schedule it. If I'd need to explain the job every single time, I don't. That's the test. The rest is just cron syntax.

I've been thinking about this in terms of a pilot's pre-flight checklist. A good checklist doesn't replace the pilot's judgment. It frees the pilot from having to remember the boring parts so their judgment has room to operate on the interesting parts. That's the frame I keep coming back to. Autopilot for the checklist items. Pilot for the landing.

What Scheduled Tasks actually is (and why it's not local cron)

Claude Code Scheduled Tasks is Anthropic's cloud-side runner for recurring agent work. You give Claude a prompt, attach one or more repos, pick a schedule, and the job runs on Anthropic's infrastructure on the cadence you set. Hourly. Daily. Weekly. A custom cron string if you want to get weird on the fifth Tuesday of the month.

The important part, and the part I misunderstood for the first week: your computer does not need to be on. This is not a wrapper around the Claude Code CLI shelled out from a launchd plist. It's a proper remote execution environment. I can close my MacBook, fly to Dubai, lose the laptop in a taxi, and the Monday morning standup prep still lands in my inbox at 8:00 AM GST.

If you've ever wired up a local cron job with the Claude Code CLI, you know the failure modes. Laptop asleep. Network dropped. You forgot to source your environment variables. The shell script silently errored six weeks ago and you only noticed because the Slack message never arrived. I did this dance for months.

Scheduled Tasks removes all of that. The job runs in a managed sandbox, the repo is cloned fresh, credentials are scoped, logs persist, and you get a structured record of every run including Claude's output and any files it touched. Anthropic published the official announcement and a reference for the schedule syntax that are worth a skim before you start.

Napkin math on cost: my five tasks consume roughly 40 minutes of compute per week across all runs. At current pricing that's under $8/month. My old self-hosted cron on a DigitalOcean droplet ran me $12/month, broke every six weeks, and did less. Autopilot is cheaper than the pilot I was underpaying.

And the time math is worse in my favor. If I save 90 minutes of Monday morning housekeeping per week (conservative), that's roughly 78 hours a year. At the rate I'd pay myself for focused work, the cost of compute for these jobs is a rounding error. The real accounting isn't dollars, it's decisions I no longer have to make before 10 AM.

Setup: the /schedule command in about three minutes

Two ways to create a scheduled task. The web UI at claude.ai/code/schedules is the gentle one. It has a form, a cron string builder, a preview of the next five run times, a repo picker. Use it if you're new.

I use the CLI because I like my automations to live in my shell history. Here's the canonical shape:

/schedule create "daily dependency audit" \
  --repo vibecoding-ae \
  --cron "0 8 * * *" \
  --prompt "Run npm audit. Summarize critical and high vulnerabilities. If any exist, open a GitHub issue tagged security with a fix plan."

Break that down. The first argument is a human-readable name that shows up in the dashboard. --repo attaches a repo (you can pass multiple). --cron takes standard five-field cron. --prompt is the instruction Claude runs on each invocation.

To list what you've got running:

/schedule list

To inspect the last run of a specific task:

/schedule logs "daily dependency audit" --last

And to pause without deleting (my favorite, because I do this a lot during sprint crunches when I don't want more inbox):

/schedule pause "daily dependency audit"

The gotcha I hit early: prompts have to be idempotent. If you phrase them like "add a new section to the README," Claude will happily add a new section every single day. You want "ensure the README has a section titled X, creating or updating it as needed." Think declarative, not imperative. Think state this should be in, not do this thing.

One more setup note. Each scheduled task runs with a scoped token you generate when you attach the repo. I recommend giving each task its own token rather than sharing a single admin token across all of them. When something goes weird (and something will, eventually), narrow blast radius is worth more than convenience. I learned this after a prompt I wrote on a Tuesday tried to push to main on a Wednesday. Separate tokens let me revoke one task's access in seconds without breaking the other four.

The five tasks actually running in my background

1. Daily dependency audit (every weekday at 8:00 AM)

/schedule create "daily dependency audit" \
  --repo vibecoding-ae \
  --cron "0 8 * * 1-5"

The prompt asks Claude to run npm audit --json, filter for critical and high severity, check if any of the flagged packages are actually imported in source (lots of audit noise comes from dev-only transitives), and if the real-world list is non-empty, open a GitHub issue tagged security with a short fix plan.

The output I get looks something like:

Scanned 1,247 packages. 3 critical, 1 high. Of those, only 1 (next transitive) is imported in /src. Opened issue #142 with proposed bump to 16.0.3. Estimated breaking change risk: low.

Time saved: about 15 minutes every weekday. That's over an hour a week I was spending reading security tables at breakfast. The real win isn't the time, though. It's that I no longer skip the audit when I'm busy, which was roughly every second week.

2. Weekly changelog generation (Fridays at 5:00 PM)

/schedule create "friday changelog" \
  --repo vibecoding-ae \
  --cron "0 17 * * 5"

Prompt: diff the last seven days of merged PRs, group them by category (feat, fix, refactor, docs), write them up in the style of prior entries in CHANGELOG.md, and open a draft PR for my review.

What lands in my inbox on Friday evening is a clean draft changelog entry. I skim it, fix the one or two things Claude got slightly wrong about intent (it's pretty good, but intent is still a human call), and merge. The post that would have taken me 45 minutes on Monday morning now takes me four minutes on Friday evening.

I used conventional-changelog for years before this. It was fine. But it couldn't tell me why a change mattered to users. Claude can, because I pointed it at the commit messages, the PR descriptions, and a short style guide I keep in docs/changelog-voice.md.

3. Nightly test suite run (every night at 2:00 AM)

/schedule create "nightly full suite" \
  --repo vibecoding-ae \
  --cron "0 2 * * *"

Prompt: check out main, run the full Playwright + unit suite, and if anything fails that didn't fail in the previous nightly, open an issue with the failing test name, stack trace, and a first-pass hypothesis about what might have broken.

Why not use GitHub Actions for this? I do, for CI on PRs. But GitHub Actions runs the suite I wrote. The nightly claude code scheduled tasks job is a different beast: it's analytical. When a flaky test flakes for the fourth time, Claude notices and files a flakiness issue. When a test breaks because of a timezone shift at 2 AM UTC, Claude notices. That's not something my vanilla CI does.

Cost tradeoff here: roughly 8 minutes of compute per night, so about 4 hours a month. Still cheap. Much cheaper than the half-day I used to lose to a Monday morning "why is everything red" debugging session.

4. Monday morning standup prep (Mondays at 7:30 AM)

/schedule create "monday standup prep" \
  --repo vibecoding-ae \
  --repo content-ops \
  --cron "30 7 * * 1"

This is the one that replaced my actual Monday ritual. The prompt asks Claude to summarize: what shipped last week (by PR), what's in progress (open PRs, draft state, blockers mentioned in PR comments), what's blocked, and what I said I'd do last week that didn't happen.

That last bullet is the useful one. Claude parses my previous Monday's standup note, cross-references it with what actually merged, and tells me, with zero emotional softening, which commitments I ghosted. It's humbling. It's also the single most useful piece of software I run on a regular schedule.

The output lands in a private GitHub Gist by 7:45. I read it with my coffee. Standup at 9:00 AM is now a five-minute sync instead of a twenty-minute archaeology dig.

For more tactical setup tricks like this, the 50 Claude Code Tips guide has a section on chaining scheduled tasks with Gists that I cribbed from heavily.

5. End-of-sprint metrics (last day of sprint at 6:00 PM)

/schedule create "sprint metrics" \
  --repo vibecoding-ae \
  --cron "0 18 */14 * *"

Every two weeks. Claude pulls the sprint's closed tickets, calculates velocity, compares it against the rolling six-sprint average, flags any ticket that exceeded its estimate by more than 2x, and writes a two-paragraph retro prompt I can bring into Friday's retro meeting.

The magic here isn't the numbers. I can get numbers from Linear. The magic is the pattern-matching across sprints. "You've blown the estimate on infrastructure tickets four sprints in a row. Consider sizing them higher by default, or splitting them." That's the kind of note a good engineering manager would write if they had eight hours to stare at your board. Claude writes it in ninety seconds.

If you want a deeper framing on how scheduled tasks fit into the broader Claude Code workflow patterns (hooks, routines, subagents), the Claude Code routines complete guide is where I'd point you next. Scheduled Tasks is one tool in a larger system, and routines are the connective tissue.

When scheduled tasks fail gracefully (and when they don't)

I want to be honest about the failure modes, because the marketing doesn't cover them.

Graceful failures: the repo token expired, so the job fails, logs cleanly, and sends me an email. The suite flaked, Claude notes it, doesn't open a false issue, moves on. A dependency registry was down, Claude retries with exponential backoff, eventually fails, tells me. These are all fine. The system handles them the way you'd want.

Ungraceful failures, where I've been burned:

• Prompt drift. I once wrote a prompt that said "close any issues that look resolved." Claude did. Aggressively. I lost two real bugs that Friday. Now I never give scheduled tasks destructive permissions without a human-in-the-loop step.
• Silent success. A task that was supposed to open a PR started doing nothing because the branch name pattern changed. The job succeeded (nothing to do!) for three weeks before I noticed. Now every task writes a heartbeat line to a shared log, and I have a meta-task that alerts me when heartbeats go missing.
• Cost surprises. A recursive prompt (don't ask) burned through $40 in a day. Set budget alerts on your workspace. Seriously.

The rule I settled on: a scheduled task should be able to report, summarize, draft, and recommend. It should not delete, force-push, or deploy without human approval. Autopilot flies the plane. It doesn't land it.

Also, genuinely: some things shouldn't be scheduled. If a task fires once every three weeks, write a Makefile target and run it by hand. The overhead of maintaining a schedule (and the risk of it silently rotting) isn't worth it for rare work. I unschedule more tasks than I schedule these days. That's probably a healthy sign.

The other case where I hesitate is anything that requires nuanced judgment the first time but not the tenth. Scheduling encodes the tenth version of the judgment. If you haven't run the task by hand at least three or four times, you don't know what the tenth version looks like yet. Schedule too early and you're automating a shape of work you don't fully understand. I now wait until a task feels boring before I automate it. Boredom is the green light.

What I'd try next

The whole point of claude code scheduled tasks is that the friction of setting up automation dropped to near zero. When something drops to near-zero friction, the right question stops being what can I automate? and starts being what recurring thinking am I still doing that a checklist could do better?

I don't have a clean answer. My current experiments: a weekly "read my own writing from a year ago and tell me what I believed then that I don't believe now" task. A monthly "scan my unfinished drafts folder and pick the one most worth finishing" task. Both are half-broken. Both feel like they might be important.

If you try this and find a scheduled task that changes how you work, I genuinely want to hear about it. Reply, DM, open an issue on any of my public repos with a label called scheduled-tasks-show-and-tell. The best uses of this tool are going to come from the people using it, not from the docs.

The Monday ritual is dead. What you put in its place is the interesting question.