Open the run and read what it did. Anthropic's routines page says a green status means the session started and exited without an infrastructure error, not that the prompt's goal succeeded. Check the transcript, the output location, skipped runs and whether results changed over time.
Why status is not outcome
With a scheduled task, "it ran" and "it worked" are different facts. The routines page gives examples of failures that surface in the transcript rather than in the status indicator: blocked network requests, missing connector tools, and task-level failures. A task can be green every night while doing nothing useful.
The Desktop page adds a second category: skipped runs. The history lists every past run including skipped ones, and hovering shows why, such as the computer being asleep, the previous run still in progress, or other tasks already running.
A weekly review routine
Spend ten minutes per important task:
- Count runs. Did the expected number happen? Skipped and missing runs matter.
- Open the latest run. Read the final answer and scan the tool calls.
- Look for denials and errors. Permission denials, blocked hosts and tool failures hide here.
- Compare the output with reality. Pick one claim in the summary and verify it by hand.
- Check side effects. Branches, tickets and messages created, and whether any are duplicates.
- Note drift. Is the output getting shorter, vaguer or repetitive?
The routines page also mentions asking in the CLI why a routine did nothing, such as /schedule why did my nightly review do nothing this morning?, which lists recent runs and reads logs to explain. That requires a recent Claude Code version, so confirm it on yours.
Make success measurable
Write a success line into the prompt, then check it.
- "End every run with a single line: DONE with counts, or FAILED with the reason."
- "If no new items were found, say so explicitly rather than staying silent."
- "List every system you wrote to."
A task that must report on silence is easier to monitor than one that may legitimately say nothing. Pair this with an external check, such as an alert if no summary arrives by a given time. Detecting a silently failing scheduled scan covers that pattern for scanners.
Treat the model as a reporter, not a witness
A task's own account of what it did can be wrong. Verify against downstream logs for anything important, as in do not trust an agent's report of its own actions.
A small example
Imagine a nightly task that reads new issues and labels them. The run history shows green for two weeks. Opening three transcripts shows the issue tracker connector was removed after a permissions change, so the task has been reading nothing and reporting "no new issues". Nothing failed in the product sense. The fix took a minute, but only because someone opened a run. A line in the prompt such as "report the number of issues read" would have exposed the gap on day one.
What to keep
For audit or incident work, retain run history, transcripts for tasks that write, and the version of the prompt used. Keep the retention period aligned with your logging policy, and keep secrets out of transcripts.
Worked example: a nightly dependency report
A platform team has a cloud routine that checks a repository's dependency manifests each night and posts a short report. The run list shows green for three weeks. A reviewer opens last Tuesday's run and finds the transcript says the network was blocked for the package registry lookups, so the routine fell back to reading the lockfile only and reported "no outdated packages". The status was green because the session started and exited cleanly. The routines page describes exactly this: blocked network requests surface in the transcript, not the status.
The fix is an allowlist change to the environment. The deeper fix is to make the prompt say what a good run looks like and to fail loudly when it cannot be done.
Turn "it ran" into "it worked"
Write the contract into the prompt:
- State the inputs the task must obtain. "You must query the registry for each package. If any lookup fails, stop and report FAILED with the package name."
- State the output format, including counts. "End with: CHECKED n packages, m outdated."
- Forbid silent fallbacks. "Do not substitute guesses for missing data."
- Require a statement about empty results. "If nothing is outdated, say so and list the number checked."
Then watch for the format. A reviewer, or a second simple step, can check that the last line exists and that n matches the manifest count. That check does not need a model. A script can do it.
What to look at in each run
| Signal | Where | What it tells you |
|---|---|---|
| Run count and skips | Run history | Whether the schedule is healthy |
| Final message | Transcript | What the task claims |
| Tool calls and errors | Transcript | What it actually tried and what failed |
| Side effects | Downstream systems | What really changed |
| Duration and size | Run list | Sudden changes hint at a loop or a failure |
Sampling instead of reading everything
For tasks that run many times a day, reading each run is impossible. Sample: the first five runs after any change, then one run per day or per week, plus every run that ends in an error or runs unusually long. Set an alert for outliers if your tools allow.
Who owns the check
Name a person. The owner of the task reads runs. The sponsor reviews the sampling log monthly. If no one wants to own the check, the task is not valuable enough to run unattended, and that is a useful finding on its own.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how repeated checks surface a change between runs, and think about what you would want to see in a scheduled task review.
Quick check
Why would a run be skipped?
The Desktop page lists the computer being asleep, the previous run still in progress, or other scheduled tasks already running.
Is a clean run history proof of control?
No. It shows runs happened. You still need to verify outcomes and side effects.
How many runs should I read after changing a task?
At least the next few, and then a regular sample. Read every run that errors or looks unusual in length or output.
Sources
Last reviewed: 19 October 2026.
