Every Monday for longer than I want to admit, I paid the same tax. Pull the pipeline numbers, flag the stale deals, note what moved, write the short summary, thirty minutes of the same work, at the start of the week, forever. It was not hard, it was just standing, a recurring chore that quietly ate the first block of every Monday and reset the moment it was done.
Routines ended that tax. A Routine is a scheduled job that runs in the cloud on its own, so the Monday report now runs before I am awake and is waiting when I open my laptop. This guide is what Routines are, what makes a job a good fit, and how to turn your own standing chores into work that runs itself.
What a Routine is
A Routine is a task plus a schedule, run in the cloud. You describe what you want done and how often, and Claude runs it on that cadence without you triggering it and without your machine being part of it. It is the automation surface for recurring work: the things that should just happen on a clock, whether or not anyone remembers or is around.
The mental model is a standing instruction to a reliable colleague who never forgets and never takes a Monday off. You told them once what to do and when, and it happens, on time, every time, and lands on your desk. You are not in the loop for the doing; you are only in the loop for reading the result and, occasionally, adjusting the instruction.
Scheduled and in the cloud
The defining trait is that Routines run in the cloud, not on your machine. That is what makes them genuinely unattended: there is no dependency on your laptop being open, awake, or online. The Monday report runs at six whether you are asleep, on a plane, or on vacation, because nothing about it needs you or your hardware.
This is the difference between a Routine and running the same job locally on a schedule. A local scheduled job dies the moment your machine does; a Routine does not care about your machine at all. For anything that truly must happen regardless of where you are, the cloud is the whole point, and Routines are how you get it without building the infrastructure yourself.
What makes a good routine
Three traits make a task a good routine. It recurs, there is a real cadence, so automating it pays back every cycle. It is well-defined, you can specify what done looks like clearly enough that it runs correctly without you steering. And it is safe unattended, meaning it either only reads and reports, or its write actions are ones you have deliberately allowed to run on their own.
The tasks that fit worst are the ones that need judgment in the moment or a back-and-forth to get right. Those want you present, so they are /loop or a live session, not a Routine. A good routine is boring on purpose: the same well-specified thing, on a clock, that you are happy to have happen without watching.
A useful signal for spotting routine candidates: look for the calendar reminders you set for yourself to do the same thing. A recurring reminder that says pull the numbers or check the stale deals is a routine you are running in your own head instead of in the cloud. Every one of those is a chore you have already decided repeats, which is the exact test for whether it should be automated.
- Recurring: a real cadence, so the automation pays back every cycle.
- Well-defined: a clear definition of done it can hit without your steering.
- Safe unattended: read-and-report, or writes you have deliberately allowed.
- Not a fit: anything needing in-the-moment judgment or a back-and-forth.
Building one
Building a routine is defining the task and setting the schedule. The task is written like a brief, since it runs without you, everything it needs stated up front, the inputs, the output, the constraints, the same discipline as any async work. The schedule is the cadence: every Monday at six, every night, hourly. You set both once, and the Routine takes it from there.
The how-to below walks it. The part worth care is the task definition, because a routine that runs a vague brief every week produces vague output every week, unattended, which is worse than doing it by hand where you would catch it. Write the brief as if you will not see the result until it is done, because that is exactly the situation.
Routines vs Dispatch vs /loop
Place Routines against the neighbors. Dispatch is a one-off you hand to your own desktop from afar; it runs local, once, when you send it. /loop is hands-on iteration while you are present. Routines are scheduled, cloud, unattended, recurring. The line that separates Routines is the schedule: the work repeats on a clock, without you triggering each run.
So the quick test: is this a recurring thing that should happen on a schedule without me: Routine. A one-off I want my machine to handle now: Dispatch. Something I am iterating on right now: /loop. The three barely overlap once you ask what triggers each, which is covered in depth in the dedicated comparison.
Guardrails for unattended runs
Because a Routine runs without you, it needs the guardrails of any unattended job. Gate the writes: a routine that only reads and reports is low risk, but one that updates the CRM or sends anything should have those actions deliberately allowed and, where possible, kept to safe, reversible changes. Validate what it produces, so a malformed output does not silently flow downstream. And add an alert on completion, so the Routine reports in like a colleague instead of running in silence.
That last one is the difference between a Routine you trust and one you forget. A job that pings you done, here is the summary, one thing looked odd is one you actually rely on. A job that runs silently is one you stop checking until the day it has been quietly failing for a month. Make it speak up.
TipGive every routine an alert on completion with a one-line summary. A silent routine is one you stop trusting; a routine that reports in is one you actually rely on.
Start read-only, earn the writes
The safest way to adopt routines is to let the first version of any routine only read and report. A Monday report that pulls the pipeline and posts a summary can run unattended from day one with almost no risk, because the worst it can do is post a summary you disagree with. You get the value immediately while you learn whether the routine is reliable.
Then, once a routine has proven itself over a few cycles, you can let it take the small, reversible actions that save the next bit of work, tagging a stale deal, adding a task, updating a low-stakes field. You promote it the same way you would promote an agent or widen a permission: by evidence, one safe step at a time, never by handing a brand-new unattended job the keys to your CRM.
Where routines go wrong
The quiet killer is drift. A routine encodes assumptions, the report format, the definition of stale, the positioning it references, and when those change and the routine does not, it keeps confidently producing last quarter's version. Revisit your routines when the underlying reality shifts, the same way you would update any standing instruction that has gone out of date.
The other two are silent failure and unattended writes. A routine that fails without telling you is worse than no routine, because you are relying on output that stopped coming, which is why the completion alert matters. And a routine with unguarded write access can repeat a wrong action every cycle, so keep writes gated and reversible until you fully trust the pattern.
- Drift: the routine keeps running an assumption that has gone stale.
- Silent failure: it stops working and you keep trusting output that is not there.
- Unguarded writes, repeating a wrong action every scheduled run.
- A vague brief, producing vague output unattended where you cannot catch it.
The GTM version
Routines are where a GTM operator claws back the standing chores. The Monday pipeline report. The nightly enrichment of the day's inbound. The weekly stale-deal flag. The recurring competitive check. Each is recurring, definable, and safe to run read-and-report, which is to say each is a routine waiting to be created, and each one you build is a chore that never touches your calendar again.
The reframe that changed my Mondays: the recurring work you do by hand is a standing tax you have chosen to keep paying. A Routine is how you stop. What is the chore that resets every week and eats the same block of your time, that could have already happened by the time you looked?
How to set it up
Pick a recurring, definable chore
Choose a task that repeats on a cadence, has a clear definition of done, and is safe to run without you watching, ideally read-and-report to start. The Monday pipeline summary is the classic first one.
Write the task like a brief
Since it runs unattended, state everything up front, inputs, output, constraints, so it produces the right thing without your steering:
"Every Monday at 6am, pull the pipeline, flag deals with no activity in 14 days, summarize what moved since last week in under 200 words, and post it to our Slack channel."
TipWrite the brief as if you will not see the result until it is done, because you will not. A vague routine produces vague output every single cycle, unattended.
Set the schedule and add an alert
Set the cadence and add a completion alert with a one-line summary, so the Routine reports in when it runs instead of working in silence. Check the docs for the current way to create and schedule routines.
Review the first few runs, then trust it
Watch the first couple of runs to confirm the output is right, gate any write actions until you trust them, and revisit the routine when the underlying reality, format, positioning, definitions, changes. Then let it run.
Frequently asked questions
What is a Claude Routine?
A scheduled job that runs in the cloud on a cadence you set, without you or your machine involved. You define the task and the schedule, and it runs unattended and leaves the result for you.
Do Routines depend on my computer?
No. They run in the cloud, so they happen whether your laptop is open or not. That is the difference from running a job locally on a schedule, which dies when your machine sleeps.
What makes a task a good routine?
It recurs on a cadence, it is well-defined enough to run without your steering, and it is safe unattended, either read-and-report or with writes you have deliberately allowed. Boring and repeatable is the ideal.
How do I build one?
Define the task like a brief, with everything it needs stated up front, and set the schedule. The task definition matters most, because a vague brief produces vague output every cycle, unattended.
How are Routines different from Dispatch and /loop?
Routines are scheduled, cloud, and unattended. Dispatch is a one-off you hand to your own desktop. /loop is hands-on iteration while you are present. The schedule is what marks a Routine.
How do I keep an unattended routine safe?
Gate its write actions and keep them reversible, validate what it produces so bad output does not flow downstream, and add a completion alert so it reports in rather than running silently.
What is the biggest risk with routines?
Drift and silent failure. A routine keeps running stale assumptions if you do not update it, and one that fails quietly leaves you trusting output that stopped coming. Revisit them and make them alert on completion.
What should my first GTM routine be?
The recurring chore that eats the same block of time every week, usually the Monday pipeline report or nightly enrichment. Recurring, definable, and safe to run read-and-report, which is exactly the routine sweet spot.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.