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.
//
Search across all documentation pages
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Reviewed by Chris St. John·Last updated Jul 19, 2026