The Same Morning Routine, Every Morning
If you work at a desk, chances are your mornings start the same way: a sweep through tech news, a glance back at yesterday's work, a quick reshuffle of today's tasks. Each item takes ten minutes or so. Stacked across a year, the total is hard to ignore.
Scheduled tasks in Claude Cowork exist to hand that "same work at the same time" over to Claude. At the time you choose, a session starts automatically and runs the prompt you prepared.
What surprised me in actual use is how different the design constraints are from interactive chat. A task that runs while nobody is watching cannot ask you to clarify anything. So rather than walking through the settings screen, this article focuses on what it takes to keep tasks running reliably, unattended, for weeks — including the habits I settled on after a few quiet failures of my own.
Three Execution Patterns and When to Use Each
Scheduled tasks come in three flavors, and they map cleanly to different jobs.
Recurring. Runs repeatedly on a cron schedule — every morning, every Monday, the first of each month. This is the workhorse for digests and reports.
One-time. Fires once at a specific moment, then disables itself. "Remind me tomorrow at 3pm" creates one of these. Under the hood, the fireAt parameter holds an ISO 8601 timestamp such as 2026-06-12T15:00:00+09:00.
Ad-hoc. No schedule at all; you trigger it manually when needed. It works well as a home for templated chores — and, as we will see, as the staging ground for dry runs.
When in doubt, build the task as ad-hoc first, confirm the output by hand, and only then promote it to a recurring schedule. The detour pays for itself.
Writing Cron Expressions — The First Stumbling Block
Recurring schedules use cron syntax: five fields, reading left to right as minute, hour, day of month, month, and day of week.
┌───── minute (0-59)
│ ┌───── hour (0-23)
│ │ ┌───── day of month (1-31)
│ │ │ ┌───── month (1-12)
│ │ │ │ ┌───── day of week (0-7, both 0 and 7 are Sunday)
│ │ │ │ │
* * * * *
The patterns I reach for most often:
0 9 * * * # every day at 9:00
0 9 * * 1-5 # weekdays at 9:00
30 8 * * 1 # Mondays at 8:30
0 0 1 * * # the 1st of each month at midnight
0 */3 * * * # every 3 hours
Two details trip people up.
First, the day-of-week field. Because both 0 and 7 mean Sunday, writing 6-7 for "weekends" behaves inconsistently across cron implementations. Enumerating explicitly — 0,6 — is the safe choice.
Second, time zones. Cowork evaluates cron expressions in your local time zone. If you want 9am Tokyo time, you write 0 9 * * * and you are done — no UTC conversion. Engineers who grew up on server-side cron tend to pause here, expecting the opposite.
Use Case 1: A Morning Tech Digest
This task runs at 9:00 every morning, collects the latest news on topics I follow, and writes a summary file. I named it morning-tech-digest.
Here is the full prompt:
Search the web for news from the past 24 hours on the following topics.
Topics:
- Claude / Anthropic updates
- New tools and frameworks for AI agents
- Developer news from Apple / Google
Compile the findings into a markdown file with this structure.
File name: tech-digest-{today's date}.md
Location: the "digest" folder at the root of the workspace
Format:
# Tech Digest {today's date}
## Top Stories
(Summarize each story in 2-3 sentences. Maximum 5 stories.)
## Worth Watching
(One paragraph on the trend you consider most significant overall.)
If search results are sparse, note that in one line at the top of the
file and summarize whatever was found. Do not ask the user any
questions; complete the task autonomously from start to finish.
The cron expression is 0 9 * * *.
Notice that this prompt already contains every element of the design pattern described next: a fixed file name, a fixed location, a fixed format, a numeric cap, an instruction for the empty-handed case, and an explicit "don't ask, just finish." In a conversation you could omit all of that. Unattended, you write all of it.
Prompt Design That Survives Unattended Runs
A scheduled task starts from a blank session every time — no memory of the previous run — and you are not there while it executes. Four habits emerged from my own trial and error, and together they account for most of the difference between flaky tasks and boring, dependable ones.
1. Sign an output contract. Pin down what gets produced, where, and in what format — down to the file-name pattern. Not "write a report" but "write weekly-report-{date}.md into the reports folder with these exact headings." If the output location drifts from run to run, you can never automate anything downstream of it.
2. Quantify everything. "Recent news" becomes "the past 24 hours." "A few items" becomes "at most 5." In chat, vague words earn you a clarifying question; in an unattended run, they earn you output that varies day to day at Claude's discretion.
3. Spell out failure behavior. Some mornings the search comes up empty. Some weeks the target folder has nothing new. One line — "if nothing is found, say so in the file" — turns silence into a record. A file that says "nothing today" also doubles as proof the task ran at all.
4. Design for idempotency. Assume the task may run twice. Date-stamped file names make re-runs harmless overwrites; an explicit "replace rather than append if the file exists" prevents duplicates. This is not paranoia — catch-up runs after your Mac wakes from sleep (more below) make double execution a normal event, not an edge case.
After adopting these four, my tasks became noticeably more stable. The inverse holds too: whenever a task misbehaves, rereading its prompt almost always reveals one of the four is missing.
Use Case 2: An Automated Weekly Report
Every Friday at 17:00, this task summarizes what changed in my workspace during the week.
Inspect the files in the workspace folder and list everything
created or updated in the past 7 days.
Create a weekly report as a .md file in this format.
File name: weekly-report-{this Friday's date}.md
Location: the "reports" folder (create it if absent)
# Weekly Report ({Monday} - {Friday})
## This Week's Output
- Created: {file list}
- Updated: {file list}
## Work Summary
(3-5 sentences inferring the week's main work from file contents.)
## Looking Ahead
(Bullet points: apparently unfinished work and suggested next steps.)
If no files changed during the period, produce the report anyway
with a "no changes this week" note.
The cron expression is 0 17 * * 5.
The interesting part is the "Work Summary" section. A shell script could produce the file diff; what it cannot do is read the contents and tell you, in prose, what kind of week it was. Closing the week by skimming that paragraph on Friday evening turned out to be more satisfying than I expected.
Use Case 3: One-Time Reminders
Asking "remind me tomorrow at 2pm" in conversation is enough — Claude creates the one-time task for you. If you build one explicitly, the prompt can stay short:
Remind the user of the following.
Reminder: prepare for the 3pm design review.
Do a final pass over the Figma prototype.
Save the reminder content to the workspace as a .md file.
One property worth remembering: one-time tasks skip the randomized delay that recurring tasks carry. When punctuality matters, a one-time task is the more faithful tool.
Combining Tasks with MCP Connectors
Output does not have to stop at files. If an MCP connector is attached, a single extra line in the prompt routes results to an external service.
With the Slack connector, appending "post the summary to the #general channel in Slack" to the morning digest closes the loop from collection to team sharing. With Google Drive, a weekly report can append rows to a spreadsheet instead.
One caution from experience. Tasks that write to external services are precisely the ones that need a dry run first. A bad file you can delete; a bad Slack post you cannot unsend. My rule is to run any externally-posting task for a week in a "save what you would have sent to a file instead" variant before flipping it live.
Scheduling Multiple Tasks Without Collisions
Once you have two or three tasks, when they run becomes a design question of its own.
The single most effective change I made was staggering start times. Tasks placed in the same time slot contend with each other; spacing them 30-45 minutes apart visibly reduced dropped work.
Aligning tasks with the hours you are not actively using the Mac also helps, since tasks run while the app is open and share the machine with you. As an indie developer I am usually deep in build-and-test cycles by mid-morning, so I cluster my tasks in the early morning and around lunch.
It helps to view your tasks as a single daily timetable: digest at 9:00, folder cleanup at 9:45, weekly report Friday 17:00. Laid out on a time axis, crowded bands and empty bands become obvious at a glance.
Day-to-Day Operations — enabled, Notifications, and Sleep
Pausing and resuming. Recurring tasks can be stopped via the enabled flag — no deletion required. Pause the digest during a vacation; retire the weekly report between projects. Knowing when to switch a task off is part of operating it.
Notification control. notifyOnCompletion decides whether a finished task pings your current session. For tasks meant to hum along in the background, turning this off keeps your focus intact.
Timing jitter. Recurring tasks carry a randomized delay of a few minutes for load distribution. They will not fire at 9:00:00 sharp, so second-level precision is out of scope.
Sleep behavior. Tasks do not run while the Mac sleeps or the app is closed; skipped runs may be executed on the next launch. This is where idempotency earns its keep — if a double run is harmless, catch-up execution stops being a hazard and becomes a safety net that picks up what was missed.
Dry Runs and Logs — Defending Against Quiet Failure
The unnerving thing about unattended automation is that failure is silent. A small misreading of your instructions repeats every day while nobody watches, and you discover a week of empty digests after the fact.
My defense consists of exactly two habits.
Run it by hand once, first. Before promoting any task to a schedule, execute it manually and read the output line by line. This single dry run surfaces most ambiguities in the prompt.
Leave a trail. Instruct the task itself to "append one line with the timestamp and a summary of what was done to log.md." Combined with the explicit nothing-found notes described earlier, the log lets you distinguish silence from success at a glance.
A Checklist for When Tasks Don't Fire
Work down this list in order; the culprit is usually near the top.
- Is the Cowork desktop app running? Tasks execute only while it is open
- Was the Mac asleep at the scheduled time?
- Is the task's
enabled flag set to true?
- Does the cron day-of-week field mean what you intended? Remember 0 and 7 are both Sunday
- Is the prompt too long or trying to do too much?
That last item is the one people skip. Packing several goals into one task invites partial execution and mid-run stalls. Keep to one task, one goal — splitting digest generation and Slack posting into separate tasks is often all it takes to stabilize both.
Start with One Small Task on Monday Morning
Scheduled tasks turn Cowork from a tool that works when spoken to into a system that is already working when you arrive.
For your first task, pick something too small to hurt: a Monday-morning list of last week's files is plenty. Feel what it is like to find work finished before you sat down. Then, armed with an output contract and a dry run, widen the circle a little at a time.
I hope this saves you a few of those ten-minute mornings.