How a Routine runs: reading the run instead of trusting a green light
The verify-the-transcript habit every scheduled run needs
After this, you'll be able to describe how a Routine in Claude Code runs unattended, explain why you read the first run's transcript instead of trusting a green status, and recognize that this is a Code-track feature in research preview that a non-developer mostly understands rather than builds.
Before you start
Complete Recurring work without you first; this lesson takes the Routine you placed there and shows how a scheduled run actually behaves and how you verify it.
The idea
The one habit that decides whether you can trust a Routine is reading its first run instead of trusting a green light. A green status only means the scheduled session started and exited without an infrastructure error; it does not mean the task in your prompt actually succeeded.
A Routine runs as an unattended Claude Code session against the GitHub repository you pointed it at, cloned fresh each run, reading and writing through its connectors on the schedule you set. It runs cloud-only on Anthropic's infrastructure, so it keeps working with your laptop closed.
This is a Claude Code feature, still in research preview, so a developer typically builds and owns it. Your job as a non-developer is to understand the verify-the-run habit, which is the part that matters most.
Here is the before and after: Before, a scheduled run shows a green checkmark and you assume the weekly digest went out, then learn weeks later it was empty the whole time. After, you open that first run, read the transcript, and catch a blocked request or a missing connector before the schedule repeats the mistake.
Now try it think of one recurring result you would rely on, and write the one check you would run after the first execution: open the run and read what it actually did, not just whether it turned green.
A green status means the run finished, not that the task succeeded; reading the transcript is how you tell the difference.
Try it (14 min)
Watch out for
- Trusting a green run status. It only means the session started and exited; open the run and read what Claude actually did.
- Letting a schedule repeat an unread run. Read the first execution before you rely on the result week after week.
- Leaving a needed connector out of the Routine. If the source connector is missing, the run has nothing to read.
- Writing a thin prompt. The run is unattended, so the task and the output have to be spelled out, not opened like a chat.
- Assuming this is your job to build. A Routine is a Claude Code feature; a non-developer mostly reads and relies on its output.
Paste this into Claude
Help me understand how to verify a scheduled Routine, since I will be reading its results even if a developer sets it up. A Routine is a Claude Code feature (in research preview): an unattended cloud session that runs a self-contained prompt against a connected GitHub repository (the folder where a software project's files live, cloned fresh each run) and reads or writes through its connectors on a schedule. Here is the recurring result I would depend on: [e.g. "a Friday status digest posted to our team chat" or "a weekly summary of what changed in a project"]. Help me reason it through: 1. SUCCEED VS FINISH: explain the difference between a run that finished (a green status) and a run that actually did the task, in plain language 2. CHECK: give me a short checklist of what to read in the first run's transcript to confirm it did what the prompt asked 3. FAILURE SIGNS: name two things in a transcript that would tell me the run finished green but the task failed (for example a blocked request, or a connector that was not included) 4. MY ROLE: tell me honestly what a non-developer does with a Routine versus what a developer does Explain any term in plain language as you go.
What good looks like
- Claude clearly distinguished a run that finished (green status) from a run that did the task
- The checklist says to read the transcript, not to trust the green status
- Claude named at least two transcript signs of a green-but-failed run
- Claude explained that a non-developer reads and relies on the result while a developer builds the Routine
- You can state in one sentence why a green status is not proof of success
When this breaks
- Breaks when the run needs a domain or tool the environment blocks, because a cloud session fails closed on disallowed requests, so the result comes back empty or partial and only the transcript shows why.
- Breaks when the prompt leaves the output shape implicit, because an unattended run guesses the format each time, so the result drifts and the people who depend on it stop trusting it.
AI can help with this
Paste: 'A Routine is a Claude Code feature (in research preview): an unattended cloud session that runs on a schedule against a connected GitHub repository and reads or writes through its connectors. Explain the difference between a run that finished (green status) and a run that did the task, give me a checklist of what to read in the first run's transcript to confirm it worked, and tell me what a non-developer does with a Routine versus what a developer does.'
You can now
You can complete the lesson outcome in a real Claude chat, Project, Artifact, Connector, Desktop, or Code surface.
- You can verify that claude clearly distinguished a run that finished (green status) from a run that did the task.
- You can verify that the checklist says to read the transcript, not to trust the green status.
- You can verify that claude named at least two transcript signs of a green-but-failed run.
- You can verify that claude explained that a non-developer reads and relies on the result while a developer builds the Routine.
Key takeaways
A Routine runs as an unattended Claude Code session on a schedule, against a cloned GitHub repository, reading and writing through its connectors. A green status means the run finished, not that the task succeeded, so reading the first run's transcript is the habit that makes it trustworthy. Building it is a developer's job; verifying the result is yours.
- Read the first run's transcript before you trust a Routine, since a green status only means it finished.
- Expect a Routine to run unattended in the cloud, working in a cloned GitHub repository through its connectors.
- Include every connector the run reads from, or the scheduled session has nothing to work with.
- Spell out the output shape so an unattended run stays consistent instead of drifting each time.
- Treat building a Routine as a developer's job and reading its result as yours, since it is a Claude Code feature.
Go deeper