Claude Code Routines for Client Work: Sell the Nightly Run, Not the Hour

What a Routine Is and Why It Changes Client Work

A Claude Code routine is a prompt, one or more repositories, and a set of connectors, packaged once and run automatically. It executes on Anthropic-managed cloud infrastructure, so it keeps working when your machine is off. You attach one or more triggers: a schedule (hourly, nightly, weekdays, weekly, or a one-off time), an API trigger that gives the routine its own HTTP endpoint and bearer token, or a GitHub trigger that fires on pull request and release events. You create them from the Desktop app's Code tab, from the web at claude.ai/code/routines, or from the CLI with /schedule.

Why this matters for a builder who sells to clients: most of the money in a client relationship after launch is recurring work that is boring, repeatable, and tied to a clear outcome. Check that the build still runs. Review what changed. Write the weekly note. That is exactly the shape of work routines are designed for. Until now the honest way to deliver it was to block time in your calendar and hope you remembered. A routine turns it into something you set up once during the engagement and then get paid for month after month, which is the entire premise of [packaging a maintenance plan](/blog/package-a-maintenance-plan-for-ai-builds).

Three Routines Worth Selling First

Do not start with the clever one. Start with the three that map to a fear the client already has and produce something they can see.

1. The nightly health check with a written report. A schedule trigger runs against the client's repository each night. The prompt tells Claude to install dependencies, run the test suite, check that the build succeeds, scan recent commits and any error output for regressions, and write a short plain-English summary. The output is the raw material for the weekly client update, and it means you find out about a broken build before the client does.
2. The pull request reviewer. A GitHub trigger runs on pull_request.opened for the client's repo. The prompt carries your review checklist - the security items, the style rules, the parts of their system that are fragile - and Claude leaves inline comments plus a summary. For clients who have an in-house developer touching the codebase you built, this is the single most reassuring thing you can offer: every change gets a second set of eyes that knows the project.
3. The deploy verification. An API trigger gives the routine an endpoint. The client's deploy pipeline sends one HTTP POST after each production release, and the routine runs smoke checks against the new build, looks for regressions in the logs, and posts a go or no-go. You are selling the calm after the deploy, which is the moment most clients are most anxious.

Each of those is a full Claude Code cloud session with real shell access to a fresh clone of the repository. It can use skills committed to the repo and any connector you include, without stopping for approval. That is what makes them powerful, and it is also why the next section exists.

The Set, Report, Escalate Loop

The Profit Room's Set, Report, Escalate loop is the rule I use for every unattended job on a paid project. Set the routine up with the narrowest scope that still does the work. Make it end in a report a human reads. Write the escalation rule into the prompt itself so the routine knows what to do when something is wrong instead of quietly doing nothing.

Set means scope. A routine can reach only the repositories you select, the network and environment variables of its cloud environment, and the connectors you include. By default every connector on your account is included, and Claude can use all of a connector's tools, including writes, without asking. On a client routine, remove everything the job does not need before the first run. Keep client credentials out of environment variables that other people can see; on Pro and Max plans, the docs point you to storing API keys as credentials instead. This is the same discipline as [permissions on a local client project](/blog/claude-code-permissions-for-client-work), applied to a session where nobody is there to click no.

Report means the routine's last job is to write something down: a summary comment on the PR, a short markdown note committed to a claude/ branch, a message through a connector to a channel the client can see. A routine that only does things and never says what it did is invisible, and invisible work is the first thing a client cuts from a retainer.

Escalate means the prompt includes the condition that should get a human involved and what to do when it happens. Tests failed twice in a row? Say so loudly and stop. A dependency needs a major version bump? Open the note, do not make the change. Here is the trap the docs call out directly: a green status in the run list means the session started and exited without an infrastructure error. It does not mean the task succeeded. Blocked network requests, missing connector tools, and task failures all show up in the transcript, not the status light. So the loop closes with you actually opening the run and reading it, at least until you trust the prompt.

Setting One Up From the Desktop App

Open the Desktop app's Code tab, click Routines in the sidebar, then New routine, and choose Cloud. Choosing Local instead creates a scheduled task that runs on your machine, which is a different thing and stops when your laptop sleeps. Then work through the form in this order.

1. Write a self-contained prompt. The routine runs with nobody watching, so the prompt has to say what to do, what done looks like, and what to do when it cannot finish. Pick the model in the prompt input; it is used on every run.
2. Select only the client's repository. Each run clones it fresh from the default branch and pushes work to claude/-prefixed branches. Claude Code rejects pushes to protected branches, to branches with someone else's open PR, or to branches carrying commits by other people, which is a useful backstop but not a substitute for a clean prompt.
3. Pick the cloud environment and check its network access. The default environment allows a trusted allowlist of package registries and common development domains. If the routine needs to reach the client's own service, add that domain deliberately rather than switching to full access.
4. Prune connectors to the ones this job needs, then choose the trigger. Schedule presets are hourly, daily, weekdays, and weekly, entered in your local time. The minimum interval is one hour, so do not promise a client anything faster than that. Custom cron expressions are set from the CLI with /schedule update.
5. Click Run now before you trust the schedule, open the run, and read the transcript. Fix the prompt until the report it produces is one you would send to the client as-is.

Two operational details to write into your own checklist. If your GitHub connection expires, the routine skips runs for up to 72 hours and then switches itself off, so a lapsed token is a silent outage. And from the CLI you can ask plainly - /schedule why did my nightly review do nothing this morning? - and Claude reads the run log and explains the tool errors or denials it hit. That one command turns a mystery into a five-minute fix. Pair it with a proper [security review before handoff](/blog/claude-code-security-review-for-client-work) and the client repo is in better shape unattended than most are with a human watching.

How to Price It and How to Talk About It

Routines draw down your subscription usage the same way interactive sessions do, and there is a daily cap on how many routine runs can start per account. That is your cost of goods, and it is why the routine belongs inside a monthly plan rather than billed as a one-time setup. Fold it into [retainer pricing](/blog/retainer-pricing-for-ai-builders) as a named deliverable: nightly checks, review on every change, a written weekly note. The client is not paying for a cron job. They are paying for the fact that someone competent looks at their system every night and tells them what they saw, and the routine is what makes that promise affordable for you to keep.

In the conversation, sell the outcome and the report, never the mechanism. 'Your build gets checked every night and you get a short note every week; if anything breaks, I know before you do.' Do not promise real-time monitoring; the one-hour floor and the daily run cap make that a promise you cannot keep. Do not promise it never needs you; the escalation rule exists precisely because sometimes it does. Under-promise the cadence, over-deliver the clarity of the report, and the [weekly client update](/blog/weekly-client-update-prevents-fires) writes itself from the routine's output.