Setting Claude to run on a schedule — and keeping it on a lead

Working with Claude — CC BY 4.0

Everything else in this course has you sitting with Claude: you ask, it answers, you check the answer, you decide what next. Scheduling changes that. You set the work up once and Claude runs it later, on its own, while you’re asleep or away from the desk. That’s genuinely useful — a morning summary, a weekly tidy-up, a check that fires when something happens. It’s also where the safeguards you’ve practised matter most, because now you’re not in the room when it runs.

The trade is plain: you gain unattended repetition, you give up watching each step. This lesson is about making that trade with your eyes open.

What scheduled work actually is

In Claude Code, the feature is called routines. A routine is a saved bundle — a prompt, the repositories or files it works on, the connectors it’s allowed to use — that runs by itself when a trigger fires. It runs on Anthropic’s cloud, so it keeps going when your laptop is shut. (Availability, exact limits and menu names shift as the product moves through research preview — confirm the current state at claude.ai/code/routines or the Claude Code docs.)

A routine can be started three ways:

• On a schedule — hourly, nightly, weekly, or once at a set future time.
• By an API call — an outside system POSTs to a private web address and kicks it off.
• By a GitHub event — it reacts to something happening in a code repository, like a new pull request.

You create one at claude.ai/code/routines, or in the CLI by typing /schedule — for example /schedule daily PR review at 9am, or a one-off like /schedule in 2 weeks, open a cleanup PR.

If you don’t work with code, there are simpler scheduled-task options aimed at everyday jobs — a daily brief that reads your calendar and inbox, say — that live in the Claude desktop app rather than the developer tools. Treat the specifics of those as confirm in-app / current docs: the naming and availability have been moving, and I’d rather you check than take my word for a menu path.

The one thing to understand before you schedule anything

A routine runs with no one to say yes. In a normal chat, Claude pauses and asks before it does something with consequences. A routine doesn’t. There’s no approval prompt mid-run. It can run commands, write changes, and use every tool in the connectors you’ve attached — including ones that write to outside services — without checking in. What it can reach is fixed entirely by what you hand it at setup: which repositories, which connectors, how much network access.

So the whole of your oversight moves to two moments: before (what you allow it to touch) and after (what you check it did). Scope both tightly.

Before:

• Give it only the repositories and connectors the job actually needs. Remove the rest. A routine that reads a support channel and files tickets has no business holding your email connector.
• By default Claude can only push to branches named claude/…, which keeps it off your main branch. Leave that guard on unless you have a specific reason not to.
• Keep network access on its default level, which reaches only a standard allowlist of development domains and blocks the rest, unless the job genuinely needs to reach a particular outside service.

After:

• A green tick does not mean the job worked. This is the part people miss. In the run list, a green status means only that the session started and exited without the infrastructure falling over. It says nothing about whether Claude did the thing you asked. Blocked requests, a missing tool, a task it quietly got wrong — all of those still show green. Open the run, read what it actually did, and confirm.
• Every run is saved as a session you can open and read in full. That’s your audit trail. Use it. If a routine opens pull requests or files tickets, a human reads them before they go anywhere binding.

When NOT to automate

Automation earns its place on work that is repetitive, low-stakes per run, and easy to check afterwards. It’s the wrong tool when:

• A mistake is expensive or hard to undo — anything that sends money, messages people outside your team, deletes data, or changes production. Keep a person in the loop for those, every time.
• The task needs fresh judgement each run rather than the same recipe. If you’d want to think about it before acting, Claude will too — and it won’t have you there.
• You won’t actually read the output. An automation nobody reviews isn’t saving you work; it’s building up unchecked actions in your name. Everything a routine does — commits, messages, tickets — appears as you, under your accounts. You own it whether or not you looked.
• You’re doing it to avoid understanding the task. Schedule work you already know how to do and could check by hand. Don’t schedule work you’re hoping Claude will figure out unsupervised.

A fair rule of thumb: if you wouldn’t hand this task to a capable new staff member on their first week without reviewing their work, don’t hand it to an unattended routine either.

Staying in command

You keep the controls the whole time. You can pause or resume a schedule, run it now to test it, edit the prompt and permissions, or delete it. Start a new routine paused or as a one-off, watch the first couple of runs closely, and only widen what it can touch once you’ve seen it behave. In a team or enterprise account, an owner can switch routines off for everyone — which matters if you’re setting policy rather than just using the feature.

Scheduling is one of the sharper tools in the box. It pays off when the work is dull, repeatable and checkable, and you keep reading what comes back. The moment you stop reading, you’ve stopped being in charge of it — and that, not the schedule itself, is the risk.

This is general education, not legal advice. If a scheduled process touches personal data, money, or anything with regulatory weight, get advice from someone qualified for your situation.