Scheduled Tasks & Routines Best Practices
Before turning on a new routine, it is worth working through a short checklist covering cadence, scope, and monitoring - the three areas most likely to cause a routine to disappoint you later if skipped early.
How to Use This List
- Work through each lettered group before saving a new routine, not just once after something has already gone wrong.
- Revisit the checklist any time you widen a routine's access or change its underlying task.
- Treat this as a starting discipline, not a one-time gate - the habits below matter most in the weeks after a routine first goes live.
A - Cadence
- Match cadence to how fast the underlying source actually changes, not to how important the task feels. A source that updates daily doesn't need an hourly routine just because the topic matters.
- Default new routines to daily unless you have a specific reason for hourly or weekly. Daily balances freshness and noise well for most first routines; tighten or loosen only once you've seen real runs.
- Confirm the routine reports "nothing new" plainly on quiet runs. A cadence that's tight relative to the source will produce quiet runs often - make sure those runs read as honest, not padded.
- Revisit cadence after the first several runs, not just at setup. The right cadence is easier to judge once you've seen how often the source genuinely changes in practice.
B - Scope
- Grant only the connected tools and Skills the routine actually needs. Unused access is unused risk on a run nobody is watching in real time.
- Start read-only unless the task genuinely requires a write action. A read-only routine's worst-case failure is a wrong summary; a write-enabled routine's worst case is a wrong action.
- Review what a packaged Agent Skill assumes about tool access, not just the routine's headline prompt. A Skill can carry its own access expectations beyond what the top-level instructions state.
- Treat every scope widening as a deliberate decision, not a default. Ask specifically what the new access is for before granting it.
- Re-audit access periodically as a routine's purpose evolves. A routine that started narrow and grew responsibilities over time may be carrying access it no longer strictly needs.
C - Instructions and Failure Handling
- Write the prompt as if no one will be present to answer a clarifying question, because no one will. Ambiguity that a live chat would resolve instantly becomes a silent gap in an unattended run.
- Include an explicit instruction for what to do when a step can't be completed. Without it, a routine may quietly skip a failed step rather than reporting the problem.
- Name the exact source and time window for any digest or summary routine. Vague scoping produces repetitive or inconsistent output over time.
- State clearly what counts as worth including versus what to skip. This single decision does more for output quality than any formatting instruction.
D - Monitoring After You Turn It On
- Read the first several scheduled runs in full, not just the headline. Early runs are your best chance to catch a prompt that needs tightening before bad habits set in.
- Watch for repeated identical failures across consecutive runs. A single quiet failure may be a fluke; the same failure repeating is a setup problem worth investigating directly.
- Compare output against what you independently know changed, when you can. This is the clearest way to catch a routine that's silently producing incomplete results.
- Move to periodic spot checks only after you trust the routine's behavior. Close review shouldn't stop the moment a routine seems to be working - ease off gradually, not all at once.
E - Ongoing Hygiene
- Periodically review which routines are still actually useful. A routine that no longer reflects current priorities is easy to forget about precisely because it runs unattended.
- Retire or pause routines whose underlying source or purpose has gone stale. An unattended routine reporting on something no one cares about anymore is still consuming attention every time its output is read.
- Keep a short record of why each routine exists and what it's scoped to do. This makes future audits of cadence, scope, and relevance much faster.
Applying This Checklist in Order
- Cadence and Scope (A-B) come first because they're the settings that shape every future run - get these roughly right before worrying about instruction wording.
- Instructions and Failure Handling (C) come next, since they determine how gracefully the routine behaves once cadence and scope are set.
- Monitoring and Hygiene (D-E) are ongoing, not one-time - revisit them for the life of the routine, not just at setup.
FAQs
Which group of this checklist matters most for a first routine?
Cadence and Scope (A and B) matter most at setup, since they're the settings hardest to notice are wrong once a routine is running unattended. Instructions and Monitoring matter continuously after that.
Is it okay to skip the failure-handling instruction for a simple routine?
It's tempting for a simple routine, but even simple tasks can hit an unavailable tool or empty data source - an explicit failure-handling instruction costs one line and prevents a silently incomplete report.
How long should I keep closely reviewing a new routine's output?
Through the first several scheduled runs at minimum - enough to see how it behaves across at least one normal cycle and, ideally, one genuinely quiet run.
What's the most commonly skipped item on this checklist?
Re-auditing scope after a routine's purpose has evolved. Access granted for an earlier, narrower version of a task tends to persist unnoticed once the routine has grown beyond its original job.
Should I apply this whole checklist to every routine, even small ones?
The core items - matching cadence to the source, scoping access narrowly, and reviewing the first few runs - are worth applying to every routine. The ongoing hygiene items matter more as the number of routines you run grows.
What should I do if a routine keeps failing the same way?
Treat a repeated identical failure as a setup problem rather than a transient glitch - check the routine's connected tool access and data source availability directly instead of waiting for a future run to self-correct.
How do I know when a routine has earned looser monitoring?
Once you've seen it behave consistently across several runs, including at least one quiet run handled honestly, it's reasonable to move from close review to periodic spot checks.
Does this checklist apply the same way to prompt-based and Skill-based routines?
Yes, with one addition for Skill-based routines: also review what the packaged Skill itself assumes about tool access, since that can extend beyond what the routine's top-level prompt states.
What's the risk of not periodically reviewing which routines are still useful?
Stale routines quietly keep their standing access and keep producing output someone has to read, even after their original purpose has faded - the cost is attention and unnecessary access, not a dramatic failure.
Is "narrow scope" ever the wrong call?
Narrow scope is the right starting point for essentially every routine; widening it later is easy once you understand exactly what additional access the task genuinely needs.
Related
- How Scheduled Tasks and Routines Work in Cowork - the mental model this checklist assumes.
- Choosing the Right Cadence: Hourly, Daily, or Weekly Routines - the reasoning behind the cadence items above.
- What Happens When a Scheduled Task Runs Without You Watching - the full picture behind the failure-handling and monitoring items.
- Connected Tools and Skills: What a Routine Can Access While Running - the deeper scoping discussion behind the scope items above.
- Setting Up a Weekly Digest Routine Step by Step - a worked example applying most of this checklist end to end.
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.