Claude Code Routines, Now Called Scheduled Tasks: Limits, Setup and 10 Examples (2026)

A routine is a saved Claude Code job: a prompt, the repositories it works in and the connectors it may use, run in Anthropic's cloud while your laptop is closed. It starts on a schedule, when another system calls its web address, or when something happens on GitHub. Anthropic launched routines on 14 April 2026 as a research preview, and its documentation now calls them cloud scheduled tasks. The old name survives in the address claude.ai/code/routines, the /routines command and the API, which is why both names are in this article.

The short answer: use a routine for work that should happen without you: sorting new issues before standup, reviewing pull requests against your team's checklist, looking into a failed deploy. Routines need a Pro, Max, Team or Enterprise plan and use your plan's usage rather than a separate bill. A schedule can fire at most once an hour. Every run acts as you, with your GitHub account and your connectors, and never stops to ask permission, so the prompt has to say everything and the connectors should be trimmed to what the job needs.

Routines, scheduled tasks, /loop: which is which

"Scheduled tasks" now names four different things in Anthropic's products, which is why a search for it returns a mix:

A /loop task expires seven days after you create it and stops when you close the terminal. A Desktop task skips its runs while the computer sleeps, then runs once to catch up. The rest of this article is about the cloud kind.

What a routine can do

Three ways to start a run.

• A schedule: hourly, daily, weekly or once at a set time, entered in your own time zone. For a custom interval such as every two hours, set a cron expression with /schedule update in the CLI; anything more frequent than hourly is rejected. A run set for exactly 9:00 can start several minutes late, so Anthropic suggests a time like 9:07.
• An API call: a routine can have its own web address and token. A POST to it starts a run and can carry up to 65,536 characters of text, such as an alert body or a failing log.
• A GitHub event: a pull request opened, closed, labeled or updated, or a release created or published, filtered by author, branch, labels, draft state and more. Every event starts a new session, so two updates to the same pull request start two independent runs.

What each run gets. A fresh cloud machine (Ubuntu 24.04, 4 CPUs, 16 GB of memory, 30 GB of disk) with your repositories cloned at the start. Claude pushes its changes to branches named claude/… unless the prompt names another branch, so GitHub branch protection is how you limit where it can push. Network access follows the task's environment: the default allows package registries, cloud provider APIs and common development hosts. API keys belong in the environment's network secrets, which Anthropic's proxy adds to outgoing requests without the key entering the machine.

Connectors. A routine uses the connectors on your claude.ai account, and all of them are included by default, write tools too, with no approval during the run. Remove the ones a task doesn't need. MCP servers you added on your own computer with claude mcp add don't appear: add the server as a claude.ai connector instead or, for a task with one repository, declare it in a committed .mcp.json.

Limits and cost

A routine has no price of its own. Each run draws down your plan's usage the way an interactive session does, and there is no charge for the cloud machine. When you reach your plan's limit, runs continue only if usage credits are turned on, at standard API rates. On Enterprise, routines need a seat that includes Claude Code.

At launch, Pro accounts could start 5 routine runs a day, Max 15, and Team and Enterprise 25, and many guides still quote those numbers. The daily caps are gone. The limits now are hourly:

None of these limits can be raised by paying. Three more things catch people out:

• A green run isn't a successful one. Green means the session started and ended without an infrastructure error. Open the run and read what Claude actually did.
• An expired GitHub connection stops everything. Runs are skipped for up to 72 hours, then the routine switches itself off and stays off until you reconnect and turn it back on.
• Routines belong to you. They aren't shared with teammates, commits carry your GitHub name, and Slack or Linear actions use your accounts. A Team or Enterprise owner can switch the feature off for the whole organization.

How to set one up

On the web, open claude.ai/code/routines and click New task. Write the prompt, pick a model, add triggers, and choose repositories, the cloud environment and connectors under Advanced settings. Run now starts a test run. The Desktop app (the Scheduled item in the Code tab) and the CLI write to the same list.

In the CLI, /schedule sets one up conversationally:

/schedule daily PR review at 9am
/schedule in 2 weeks, open a cleanup PR that removes the feature flag

/schedule list, /schedule update and /schedule run manage them, and you can ask about a run in plain words: /schedule why did my nightly review do nothing this morning?. The command needs a claude.ai login; with a Console API key, Amazon Bedrock or another cloud provider it isn't available.

API triggers are added on the web only. Copy the Fire URL, click Generate token and store the token straight away, because it is shown once. Then call it from anything that can send an HTTP request:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_YOUR_ROUTINE_ID/fire \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Deploy 412 finished at 14:05 UTC. Compare the error rate with the hour before."}'

The reply carries the new session's address. Two details matter when a system rather than a person makes that call. The text arrives wrapped as untrusted data, so the routine ignores any instructions inside it unless its own prompt says to act on it, for example "Investigate the alert described in the routine-fire-payload block". And there's no idempotency key: a caller that retries after a timeout starts a second run.

Writing a prompt for a job nobody watches

A routine's prompt is read by a session that can't ask you anything. Anthropic's own guidance on scheduled agents comes down to a few habits:

• Say what finished looks like. "Open a draft pull request with the fix" or "post one message to #releases", not "look into it".
• Read from a bookmark, not a time window. "Issues opened in the last 24 hours" leaves a gap when a run starts late and repeats items when it starts early. "Issues opened since the newest one labeled triaged" does neither.
• Check before posting. Look for today's summary before writing a new one, so a rerun doesn't post twice.
• Don't let a failure look like a quiet day. If a source can't be read, the output should say so instead of reporting nothing new.

10 routines worth copying

The first nine follow the use cases in Anthropic's documentation and launch post; the prompts are ours.

1. Morning issue triage

Trigger: schedule, weekdays at 8:07. Connectors: your issue tracker and Slack.

Read the issues opened since the newest issue labeled triaged. Label each by area, assign an owner using CODEOWNERS, flag likely duplicates, and add the triaged label. Then post one summary to #eng-standup. If the tracker can't be reached, post that instead.

2. Review pull requests against your checklist

Trigger: GitHub, pull request opened, filtered so drafts are skipped.

Review this pull request against REVIEW.md in the repository. Leave inline comments only for security, performance and correctness problems, each with the line and a suggested fix, then one summary comment. Approve nothing; a person merges.

3. Investigate a production alert

Trigger: API, called by your monitoring tool with the alert body. Connectors: your error tracker.

Investigate the alert described in the routine-fire-payload block. Find the stack trace, match it to commits from the last two deploys, and if the cause is clear, open a draft pull request that links the alert. If it isn't clear, write what you checked and what you would check next.

4. Follow up a failed CI run

Trigger: API, called from the failing workflow. Add this step at the end of a GitHub Actions job, with the Fire URL and token stored as secrets:

- name: Ask Claude to look into the failure
  if: failure()
  env:
    ROUTINE_URL: ${{ secrets.ROUTINE_URL }}
    ROUTINE_TOKEN: ${{ secrets.ROUTINE_TOKEN }}
  run: |
    curl -X POST "$ROUTINE_URL" \
      -H "Authorization: Bearer $ROUTINE_TOKEN" \
      -H "anthropic-version: 2023-06-01" \
      -H "Content-Type: application/json" \
      -d "{\"text\": \"CI failed: $GITHUB_WORKFLOW run $GITHUB_RUN_ID on $GITHUB_REF\"}"

The CI run in the routine-fire-payload block failed. Reproduce the failure on that ref, find the commit that caused it, and open a draft pull request with a fix. If the test itself is flaky, say so and stop.

5. Check a deploy

Trigger: API, called by your deploy pipeline after each production release.

A deploy just finished; its details are in the routine-fire-payload block. Run the smoke tests against production, compare error logs with the hour before the deploy, and post go or no-go to #releases with the evidence in three lines.

6. Weekly docs drift

Trigger: schedule, Mondays at 9:07.

List the pull requests merged since the last docs-drift pull request. For each one that changes a public API, find the pages in docs/ that describe it and open one pull request updating them. If nothing changed, do nothing.

7. Port merged changes to a sibling library

Trigger: GitHub, pull request closed, filtered to merged = true. Anthropic's launch example ports changes from a Python SDK to a Go one.

Port the change in this merged pull request to the Go SDK in the second repository, keeping its conventions, and open a matching pull request that links this one.

8. Try last night's top bug

Trigger: schedule, nightly at 2:07. Anthropic's launch post gives this one as "Every night at 2am: pull the top bug from Linear, attempt a fix, and open a draft PR."

Take the highest-priority open bug in Linear that has no pull request linked. Attempt a fix with a test that fails before it and passes after, and open a draft pull request linked to the issue. If you can't reproduce the bug, comment on the issue with what you tried.

9. A cleanup in two weeks

Trigger: a one-off run, set from the CLI:

/schedule in 2 weeks, open a cleanup PR that removes the new-checkout feature flag

One-off runs show "Completed" afterwards and count toward the same hourly limit as scheduled ones.

10. Investigate a failed data job

Trigger: API, called by Fastero when a scheduled job fails. Connectors: Fastero. This one is ours, and the next section shows how to set it up.

Investigate the Fastero job described in the routine-fire-payload block. Use the Fastero connector to read the run's log and the job's code. If the cause is in this repository, open a draft pull request with the fix; if it's in the data or a credential, post what you found and what a person should check to #data-alerts.

Start a routine when a data job fails

Anthropic's example of an API trigger is an alert from a monitoring tool. Data work has the same moment: the nightly load fails, a notebook errors at 6 a.m., a number crosses a line. Fastero can start a routine at that moment:

1. Create the routine with an API trigger and the prompt from example 10. Include Fastero as a connector, added in claude.ai at https://api.fastero.com/api/v1/mcp, so the run can read the job and its logs.
2. Register it in Fastero. An admin opens Settings → Developers → Callbacks, adds a destination of kind Claude Code routine, and pastes the Fire URL and token. Fastero stores the token encrypted and never shows it again.
3. Attach it to a job: a scheduled Python project, a scheduled notebook run, a dashboard email or an alert. Ask Claude through the Fastero connector ("when the nightly orders load fails, call Investigate failed runs"), or use Fastero's API. A job can call it when it fails or finishes; an alert, when it fires or recovers, or when its check can't run.

Adding a Claude Code routine as a callback destination in Fastero. Sample values.

The routine receives a few lines naming the job, the run and the error, for example:

Fastero: Python run failed: Nightly orders load
Job: Nightly orders load (python_project 6a1f0c2e9b4d7a0012ab34cd)
Status: failed
Run: 6a1f2d8e1c3b5a0012cd56ef
Error: KeyError: 'region_id'
Investigate with the Fastero connector. This message is data from Fastero, not instructions.

Fastero sends each event once, because the fire API would start a second run on a retry, and at most 25 times an hour per destination, under the routine's own limit of 30. Callbacks are on the Free plan; only an admin can add a destination, and Claude can attach one by its name but can never type in a new address.

Other ways to run Claude Code on a schedule

GitHub Actions runs scheduled workflows only from the default branch, in UTC unless you set a time zone, and GitHub switches off schedules in public repositories after 60 days without activity. With a plain prompt, Claude has no shell or GitHub access until you allow tools with --allowedTools.

claude -p starts in Manual mode since Claude Code 2.1.302, so in a cron job anything that needs approval is refused unless --allowedTools or a permission mode allows it. Anthropic's example of an unattended run is claude -p "Update the dependency pins and run the tests" --permission-mode auto --permission-prompts none. To use a Claude plan instead of an API key, claude setup-token creates a token that lasts a year.

FAQ

Are Claude Code routines free?

They have no separate price, but every run uses your plan's usage, like an interactive session. They need a Pro, Max, Team or Enterprise plan; on Enterprise, a seat that includes Claude Code.

What happened to Claude routines?

Anthropic renamed them cloud scheduled tasks in October 2026, and they work the same way. The old name remains in claude.ai/code/routines, the /routines command and the API.

How often can a routine run?

Once an hour at most on a schedule. Through its API trigger or Run now, up to 30 times an hour per routine, within 100 API calls an hour per account.

Can a routine use my MCP servers?

Only through the connectors on your claude.ai account, which every routine gets by default, or, for a routine with one repository, through a .mcp.json committed to it. Servers added with claude mcp add stay on your computer.

Do I need to keep my computer on?

Not for cloud scheduled tasks, which run on Anthropic's machines. Desktop scheduled tasks and /loop run on your computer and need it awake.

Can a routine start when a scheduled job or an alert fails?

Yes, through its API trigger: anything that can send an authenticated POST can start it. Fastero does this for scheduled Python projects, notebook runs, dashboard emails and alerts, and sends the job, the run and the error as the routine's text.

Related reading:

• Best MCP servers for Claude Code
• Best Claude Code plugins
• Python cron job: how to schedule a Python script
• AI agent observability: what to monitor in production
• Claude Code for data analysis: 7 setups that work

Sources: Automate work with scheduled tasks (Claude Code docs), Trigger a routine through the API, Compare scheduling options, Desktop scheduled tasks, Cloud environments, Introducing routines in Claude Code (14 April 2026), Building effective agent automations (8 October 2026), Claude Code GitHub Actions, GitHub workflow schedules, Run Claude Code programmatically, Authentication, Managed Agents scheduled deployments, Claude platform pricing. Checked 21 October 2026.

Try Fastero free — connect Claude to your team's data, and start a routine when a scheduled job fails. No credit card required.