zerotoclaude
Module 04/Advanced Usage/Lesson 06

Background tasks and scheduling

Long-running jobs, cron-based agents, and 'wake me up when CI is green.'

9 min read

Most tasks finish in a few seconds. Some take minutes. A few take hours. And occasionally you want something to happen at a specific future time — every morning at 9, every Monday, after CI finishes — without you sitting at the terminal staring at the prompt. This lesson covers all three: background tasks, scheduled runs, and the self-paced loop.

Background tasks

Sometimes Claude is about to do something that'll take a while — a long build, a big test suite, a data fetch from a slow API. You don't need to wait. You can launch the command in the background and continue with other work. When the background task finishes, Claude is notified and can pick up where it makes sense.

The mechanism: any tool that supports it has a run_in_backgroundflag. Claude can set it for shell commands and subagents. Background tasks emit notifications on completion, so Claude doesn't need to poll — it gets pinged when there's something to react to.

Don't poll, get notified
The right pattern for background work is to start the task, switch to something else useful, and let the system tell you when the task is done. Polling — repeatedly checking "is it finished yet?" — wastes tokens and time. Trust the notification.

Subagents in the background

Background subagents are the most powerful form of this pattern. You can spawn three different subagents — one researching, one auditing, one drafting — all in the background. Each runs in parallel. As each one finishes, you receive its result and can synthesise. You've compressed what-would-be-hours of serial work into the time of the slowest single task.

The discipline: each subagent needs a self-contained brief, because they don't see each other or your main thread. Write the prompts carefully; the cost of fixing a misunderstanding mid-flight is high when the agent is running unattended.

Scheduled tasks

For work that should happen on a clock — every day at 9 AM, every Monday, the 1st of every month — Claude Code supports scheduled agents (sometimes called routines or cron jobs, depending on the setup).

Examples of what people actually schedule:

  • A morning briefing — read overnight emails and Slack messages, summarise into a digest.
  • A weekly metrics report — query the database, build a chart, post to a channel.
  • A nightly health check — run a suite of integration tests, alert if any fail.
  • A monthly housekeeping pass — clean up old branches, audit dependencies, flag stale issues.

Each one is a small, repeatable task that would be annoying to remember but easy to delegate. Once set up, they just keep happening.

The self-paced loop

Some tasks aren't time-based but condition-based. "Wait until CI is green, then merge." "Wait until this long-running export finishes, then process the data." You don't know how long it'll take, only what to wait for.

For these, Claude Code has a self-paced loop mode. Claude can check, wait, check again, wait longer, until the condition is met — without you having to nurse it. The agent picks appropriate intervals (short waits for things changing fast, long waits for things changing slowly) and reports back when the condition fires.

The cost discipline

Background and scheduled tasks consume tokens too. Every wake-up is a fresh call. Three guidelines:

  1. Don't poll faster than the underlying thing changes. Checking CI every 10 seconds when CI takes 8 minutes is 47 wasted calls.
  2. Make scheduled tasks idempotent. If a task runs twice by accident, the result should be the same as running it once. Otherwise duplicates compound.
  3. Add a kill switch. For anything that runs unattended, there should be a way to stop it from a single command. Long-running loose agents are how unexpected bills get made.

The right kinds of work to send into the background

Not everything benefits from being backgrounded. Sometimes the overhead of context-switching costs more than the wait. The tasks that genuinely win:

  • Anything that involves waiting on an external system (build, deploy, CI, slow API).
  • Wide, exhaustive searches you don't need the intermediate steps of — "find every X across the codebase".
  • Independent investigations you'd be running in parallel anyway.

Tasks that don't — anything where you'll need to keep steering as it progresses. Background works when you've already decided what done looks like.

Use notifications wisely
Most platforms support desktop or mobile notifications when a background or scheduled task finishes. Wire one up. It lets you truly walk away from a long task and trust that you'll be told when there's something to look at.
What to take with you
  • Background tasks let you run long work in parallel without blocking your main session. Notifications fire on completion — don't poll.
  • Scheduled agents (routines / cron jobs) handle clock-based recurring work: morning briefings, weekly reports, nightly checks.
  • Self-paced loops handle condition-based waits — "until CI is green," "until the export finishes."
  • Cost discipline: don't poll fast, make tasks idempotent, add a kill switch.