What Happens When a Scheduled Task Runs Without You Watching
The entire point of a routine is that it runs when you are not there to watch it.
That is also the reason unattended runs need a different kind of thinking than a normal chat.
There is no one present to catch an error as it happens, redirect Claude mid-task, or clarify an ambiguous instruction.
This page walks through what actually happens during an unsupervised run, how errors surface, and what a careful operator should check after the fact.
Summary
- Core Idea: An unattended run follows the same steps as any Cowork task, but without a person present to intervene if something goes wrong mid-task.
- Why It Matters: Errors that would be caught instantly in a live chat can instead sit unnoticed until someone checks the routine's output later.
- Key Concepts: unattended run, failure surfacing, retry behavior, post-run review.
- When to Use: Whenever you are relying on a routine's output without personally watching it execute - which is every scheduled run, by definition.
- Limitations / Trade-offs: A routine can only handle failure as gracefully as its prompt or Skill anticipates; it cannot improvise a fix to a problem it wasn't told how to handle.
- Related Topics: connected tool scoping, cadence selection, routine setup basics.
Foundations
When a scheduled trigger fires, Claude works through the packaged prompt or Skill exactly as it would in a live conversation - reading the instructions, using whatever connected tools are authorized, and producing an output.
The difference is entirely about what happens when something does not go as planned.
In a live chat, an error or a confusing result gets caught in the moment - you see it, and you can redirect Claude immediately.
In an unattended run, that same error either gets absorbed into the routine's handling of it, or it shows up later in the output, sometimes only as something subtly missing or incomplete.
The practical upshot is that a routine's instructions need to anticipate failure explicitly, not just describe the happy path.
Mechanics & Interactions
A run can hit trouble at a few different points: a connected tool might be unavailable, a data source might return nothing useful, or a step in the instructions might not apply cleanly to what Claude actually finds.
How visibly that trouble surfaces depends heavily on how the prompt or Skill was written.
A routine told to "report clearly if you couldn't complete a step and why" will produce an honest, useful account of what went wrong.
A routine with no such instruction may instead produce output that looks complete but quietly skipped the part that failed - which is far more dangerous precisely because it looks fine at a glance.
Scheduled trigger fires
-> Claude attempts each step of the packaged instructions
-> Step succeeds -> continues
-> Step fails or is blocked -> depends on how the prompt/Skill was written to handle it
- explicit failure handling -> reports the problem clearly
- no failure handling -> may produce incomplete or misleading output
-> Run ends; output is whatever was produced, complete or notThis is why the failure-handling instructions matter as much as the "what to do" instructions when you write a routine.
Telling Claude what to do if a connected tool is unreachable, or if a data source is empty, is not an edge case to skip - it is a core part of making an unattended run trustworthy.
Advanced Considerations & Applications
Because no one is watching in real time, the practical safety net for a routine is the habit of reviewing its output after each run, at least until you trust it.
This is especially true early on, before you have seen enough runs to know how the routine typically behaves.
A routine that silently fails once might be a fluke; the same failure repeating across several runs is a sign the underlying prompt, Skill, or tool access needs attention.
It also matters to distinguish between a run that failed outright and a run that succeeded but had nothing to report - both can look similar from a glance at a short output, but they call for very different responses from you.
| Failure Mode | What It Looks Like | What to Do |
|---|---|---|
| Explicit failure report | The output clearly states a step could not be completed and why | Investigate the specific blocker named (tool access, missing data, etc.) |
| Silent partial completion | Output looks complete but is missing a section it should have covered | Compare against what you expected; tighten the prompt's failure-handling instructions |
| Genuine "nothing new" | A short, plain statement that there was nothing to report this run | No action needed - this is a healthy, working routine on a quiet day |
| Repeated identical failure | The same problem shows up across multiple consecutive runs | Treat as a setup issue - check tool access or data source availability directly |
Retry behavior is another piece of this: whether a routine automatically retries a failed step, or simply reports the failure and waits for its next scheduled run, depends on how the routine and its connected tools are configured. Either way, the operator's job is the same - build the habit of checking, especially while a routine is new.
Common Misconceptions
- "If a routine doesn't error out, it must have worked correctly." - A routine can complete without an explicit error while still having silently skipped part of the task; completion is not the same as correctness.
- "Unattended means unmonitored forever." - Unattended describes the run itself, not your relationship to its output; reviewing results after the fact is still your responsibility.
- "A failed step means the whole routine is broken." - A single failed run is often a signal to investigate, not evidence the routine needs to be scrapped - especially if it hasn't repeated.
- "Claude will always tell me clearly when something went wrong." - Only if the prompt or Skill explicitly asks for that; failure reporting has to be instructed, not assumed.
FAQs
What actually happens if a connected tool is unavailable mid-run?
- Claude attempts the step using the tool as instructed.
- If the tool is unreachable, what happens next depends on whether the prompt told Claude how to handle that case.
- With explicit instructions, Claude reports the blocker clearly; without them, the output may simply be missing that part of the task.
How would I know if a routine is silently failing?
Compare the output against what you independently know changed, especially in the first several runs. A pattern of oddly thin or incomplete output, especially around the same section each time, is the clearest sign.
Does a routine automatically retry a failed step?
Retry behavior depends on the routine's configuration and the connected tools involved; it is not guaranteed by default, which is another reason explicit failure-handling instructions in the prompt matter.
Should I check every single scheduled run's output?
Closely at first, yes - especially for the first several runs of a new routine. Once you trust its behavior, periodic spot checks are usually enough, though it is worth staying in the habit.
What's the single best thing I can add to a prompt to improve failure handling?
An explicit instruction to report clearly when a step could not be completed and why, rather than silently continuing or padding the output to look complete.
Is a "nothing new to report" output the same as a failure?
No - a genuine, plainly stated "nothing new" is a sign of a healthy routine on a quiet day. It only becomes a concern if you know something did change and the routine missed it.
What should I do if the same failure repeats across several runs?
Treat it as a setup problem rather than a one-off glitch - check the routine's connected tool access and the availability of its data source directly, rather than waiting for another run to self-correct.
Can a routine ask me for help when it gets stuck?
No one is present in real time during a scheduled run, so a routine cannot pause to ask a clarifying question the way a live chat can. This is why writing clear failure-handling instructions up front matters.
Does this failure-handling behavior differ from a normal, non-scheduled Cowork task?
The underlying mechanics are the same - a routine is simply an autonomous Cowork task on a timer, so the same unattended-execution considerations apply either way.
What's the biggest risk of not reviewing a routine's output?
A silently incomplete report can look fine at a glance while actually missing information you were relying on it to surface - the risk isn't dramatic failure, it's quiet, unnoticed gaps.
Related
- How Scheduled Tasks and Routines Work in Cowork - the underlying mental model for how a run proceeds.
- Connected Tools and Skills: What a Routine Can Access While Running - how tool scoping affects what can go wrong.
- Scheduled Tasks & Routines Basics - practical steps for reviewing a routine's first runs.
- Scheduled Tasks & Routines Best Practices - a checklist that includes monitoring habits.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.