Claude Code Routines: What They Actually Do (And When They Beat a Cron Job)

Anthropic shipped Routines on April 14, and it took me about a day to realize it's the most underhyped Claude Code release of the year. Most of the coverage I read framed it as "Claude Code now has cron." That's technically true and entirely misses the point. Cron runs a script. A Routine runs an agent. Those are very different things, and the difference is what makes this worth caring about.

A Routine is a saved Claude Code configuration — a prompt, one or more repositories, a set of connectors — packaged once and run on a schedule, an API call, or a GitHub webhook. It runs on Anthropic's infrastructure, not your laptop. Your machine doesn't need to be online. You don't manage cron, you don't manage MCP servers, you don't manage a queue. You write the prompt, you point at the repo, you set the trigger.

This post is a practical take after running a handful of these in production for the last ten days. What they're great at, where they fall down, what the daily limits actually mean for real workflows, and where I'd still reach for a regular script instead.

What a Routine actually is

Strip the marketing away and a Routine is three things bundled together:

1. A Claude Code session config — the prompt, the model, the allow-list, the connectors.
2. Repository access — one or more repos Claude can read and edit.
3. A trigger — a schedule, an API endpoint, or a GitHub event.

When the trigger fires, Anthropic spins up a Claude Code session in their cloud, runs your prompt against your repos with your connectors attached, and shuts it down. You get the output as a run log you can review in the dashboard, with logs, diffs, and any artifacts the agent produced.

The piece I keep coming back to is "with your connectors attached." A Routine isn't a one-shot LLM call. It's the full Claude Code agent loop — tool use, file editing, bash execution, MCP servers — running unattended. That's a meaningful step up from the "ask the API to summarize this thing" automations most teams have today.

Daily limits, by plan

Routines are gated by plan tier, and the limits are tighter than I'd like:

• Pro: 5 Routine runs per day
• Max: 15 Routine runs per day
• Team / Enterprise: 25 Routine runs per day
• Overage billing: available on paid plans if you blow past the cap

Five runs a day on Pro sounds fine until you think about what you'd actually want to use this for. A nightly triage routine plus a per-deploy verification routine and a weekly docs check is already three slots, and you haven't done anything experimental. Max is the realistic floor if you're doing this seriously. Team is where it stops being a constraint.

Worth noting: a "run" is a Routine execution, not a Claude turn. A Routine that does fifty tool calls before it finishes still counts as one run. The limit is conservative, but it's not crippling once you understand what counts.

The four workflows where Routines actually shine

I've been keeping a list of every "I should automate this" thought I have during the day, and then sorting them by whether a Routine is the right tool. Four categories keep coming up.

1. Deploy verification

This is the killer use case. After a CI run, kick off a Routine that pulls the latest deploy logs, checks the error rate dashboard, scans the smoke test output, and posts a structured "looks good / here's what's off" report to Slack.

The reason this works as a Routine and not a script is that the answer isn't "did the tests pass." The answer is "is anything weird in production right now." That's a judgment call across half a dozen signals, and it's exactly the kind of thing an agent does well and a regex does poorly.

Trigger: GitHub webhook on deploy succeeded
Repos: app, infrastructure
Connectors: Sentry MCP, Datadog MCP, Slack MCP
Prompt: Check the last 30 minutes of error logs and key dashboards.
Compare against the previous 2-hour baseline. Post a brief report
to #deploys with anything that looks like a regression.

I've had this running for a week. It catches things our smoke tests don't — a slow query that didn't break anything but shows up in p95, a third-party API quietly returning a 429 on a low-traffic endpoint. Worth a slot.

2. Backlog triage

Nightly, walk every issue opened in the last 24 hours, label it, link to related issues, and flag duplicates. The reason this is a Routine and not a GitHub Action: it has to actually understand the issue text and compare semantically, not lexically. A regex can't tell you "this is the third time someone has reported the password reset bug, here are the other two issues."

This is the use case that paid for the feature for me. We had a backlog in the high three figures and our triage was always behind. A Routine running nightly, posting to a single Slack thread, keeps it in front of the team without anyone owning it.

3. Documentation drift

Weekly, walk the public API surface, compare it to the docs, flag anything that's changed. This one is interesting because the failure mode of "let docs go stale" is invisible until a customer hits it. Having an agent run through your API and your docs side by side once a week and flag mismatches is the kind of thing nobody on the team would ever volunteer to do, and it produces real, actionable issues every time.

4. The "boring side" of code review

I'm being careful with this one because the obvious version — "auto-review every PR" — is a way to either spam your team or train them to ignore the agent. The version that works is the boring version: a Routine that runs on PR open and only posts if it sees something specific you've asked it to look for. Missing tests for new public functions. Imports from deprecated modules. Migrations without a rollback note. The bar for posting has to be high.

Where I would not use a Routine

A Routine is the wrong tool when:

• The task is deterministic. If a 30-line bash script can do it, do that instead. You don't pay tokens for a cron job. Routines are for tasks that need judgment.
• The task is interactive. Routines run unattended. If the right answer is "ask Kevin in Slack," it's not a Routine.
• The task is high-stakes and irreversible. I would not point a Routine at a database migration. I'd have it draft one and open a PR.
• You need sub-minute latency. Routines spin up a fresh session each run. There's startup cost. If you need an instant response, you want a deployed Agent SDK service, not a Routine.

The honest test I use: would I be comfortable if this ran while I was on vacation and nobody noticed for two weeks? If yes, Routine. If no, something else.

Triggers in practice

Three trigger types, and they're not interchangeable:

Schedule. Cron-style. Use it for "every weeknight at 2 AM." Reliable, predictable, easy to reason about. Most of my Routines start here.

API call. A Routine endpoint you can hit from anywhere. Use it when the trigger is something Anthropic doesn't natively integrate with — your custom CI, an internal tool, a webhook from a service that isn't GitHub. The auth model is API key, scope it carefully.

GitHub webhook. PR opened, deploy succeeded, issue labeled — the events GitHub already emits. The integration is clean and means you can do "on every PR, run this Routine" without standing up your own webhook receiver.

What I keep noticing: the GitHub webhook trigger is doing a lot of heavy lifting, because so much of "what should we automate" is shaped like "react to a code event." If your team is GitHub-native, that's where most of your value will come from.

How a Routine differs from the Agent SDK

People keep asking me this, and the right answer is that they're for different jobs.

The Agent SDK is for when you're building a product feature or an internal tool that needs to embed agent behavior. You import a library, you ship code, you operate it. You handle scaling, failures, observability. You decide when an agent runs because your code calls it.

A Routine is for when you want to run the same Claude Code session you'd run locally, but on a schedule, without operating any infrastructure. You don't write code. You write a prompt and point at a repo. The whole thing is a managed product.

The mental model: Agent SDK is "build a service." Routine is "save a session." If your task fits the latter, use the latter. You'll get there in an afternoon instead of a week.

A few things I wish were different

I don't want to pretend Routines is finished. Ten days in, here's my list:

• Five runs a day on Pro is too few. I get the gating, but the tier with the most early-adopter developers is the one most likely to bounce off the limit.
• No native chaining. I want Routine A to trigger Routine B with a payload. Right now you'd do it via the API trigger, which works but feels like glue.
• Run logs are good, run history search isn't great. When you have a dozen Routines running, finding "the run from last Tuesday that failed" takes more clicking than it should.
• No staging environment for a Routine. You write it, you turn it on, it runs against production repos. A "dry run" mode that produces output without taking actions would help when you're iterating on a prompt.

None of these are dealbreakers. They're the kind of thing that gets fixed in the next two releases.

How to think about whether you need this

If you've ever caught yourself saying "we should have a script that does X," and X involves judgment or unstructured data, that's a Routine. If you're already running a cron job that pipes data through a Claude API call, that's a Routine — and the migration is shorter than you think because the Routine is already managing the session and the connectors for you.

If you've never wanted that kind of automation, you don't need this yet. Don't pay for Max for a feature you'd use once.

The mental shift Routines asks for is small but real: agents are starting to become things you schedule, not just things you talk to. Once you've had a Routine running quietly for a week, posting one good triage report a day, you stop seeing this as "Claude Code with cron" and start seeing it as "the cheapest junior teammate I've ever had." That's the bet I think Anthropic is making, and it's the right one.

The feature is in research preview. There will be sharp edges. Expect to delete a few of your first Routines after a week because they post too much, or not enough, or the prompt was too vague. That iteration is the point. By the end of the first month you'll have three or four that you'd genuinely miss if they went away — and that, more than the daily run cap, is the real measure of whether this is for you.