◈ Cowork/2026-03-19Intermediate

Claude Cowork Scheduled Tasks — Recurring Runs, Reminders, and Auto-Reports

How to set up recurring execution, one-time reminders, and automatic reports with Claude Cowork's scheduled tasks. From cron syntax to dry runs, timing spread, and idempotent prompts, with the lessons that only show up in real operation.

Cowork³³ Scheduled Tasks¹⁰ Automation⁴⁰ Recurring Execution Reminders² Reports² MCP Connectors³

✦ Premium Article

Setting Up and Running Claude Cowork Scheduled Tasks

You gather the same information every morning, then build the same report by hand every Friday afternoon. Keep doing "the same work at the same time" long enough and one day it occurs to you: maybe I don't have to be the one doing this. Claude Cowork's scheduled tasks are the feature that kicks in at exactly that moment.

That said, setting one up doesn't mean it quietly takes care of itself. Automation is wonderful, but a small misreading of an instruction can pile up, dozens of times over, while no one is watching. Alongside the setup steps, I'll fold in the operational lessons that stuck with me from keeping tasks running unattended.

Three Patterns: Recurring, One-Time, Ad-hoc

A scheduled task automatically launches a Claude session at the time you specify and runs the prompt you configured. There are three ways it can fire.

Recurring. Repeats at intervals set by a cron expression—daily at 9am, every Monday, the 1st of each month.

One-time. Runs once on a specific date and time. "Remind me tomorrow at 3pm" works this way, and the task auto-disables after it fires.

Ad-hoc. No schedule; you trigger it by hand when needed. Handy for templated work you want to run on demand.

The first thing to decide is whether the job repeats or happens once. Get this backward and a one-shot notification ends up arriving every single day.

Cron Syntax

Recurring tasks use cron expressions. Five fields, read left to right as "minute hour day month weekday."

┌───── Minute (0-59)
│ ┌───── Hour (0-23)
│ │ ┌───── Day (1-31)
│ │ │ ┌───── Month (1-12)
│ │ │ │ ┌───── Weekday (0-7, 0 and 7 are Sunday)
│ │ │ │ │
* * * * *

Common patterns: 0 9 * * * runs daily at 9am. 0 9 * * 1-5 runs weekdays (Mon–Fri) at 9am. 30 8 * * 1 runs Mondays at 8:30am. 0 0 1 * * runs the 1st of each month at midnight. 0 */3 * * * runs every three hours.

One field to watch is the weekday. Because both 0 and 7 mean Sunday, writing * * * * 1-7 when you meant * * * * 0-6 double-counts Sunday and drops Monday. This weekday gotcha is easy to avoid: do one test run right after registering and confirm the fire day. Always confirm the task fires on the days you intended.

Cron is evaluated in your local timezone. For 9am Japan time, just write 0 9 * * *—no UTC conversion needed.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦Designing recurring, one-time, and ad-hoc tasks with copy-paste-ready prompts for each pattern

✦Reading cron syntax in your local timezone, plus the weekday gotcha that quietly breaks schedules

✦Operational lessons—off-peak timing, manual dry runs, and idempotent prompts—that keep unattended runs stable

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Use Case 1: Morning Information Collection

A daily 9am task that gathers the latest on the tech topics you care about and summarizes them. Task name morning-tech-digest, description "Daily tech news digest generation."

Search the past 24 hours for the latest on these topics:

Topics:
- Claude / Anthropic latest updates
- New AI agent tools and frameworks
- Apple / Google developer news

Consolidate what you find into a markdown file:

Filename: tech-digest-{today's-date}.md

Format:
# Tech Digest {today's-date}

## Major News
(Summarize each item in 2-3 sentences)

## Key Points
(One paragraph on the developments that matter most)

Save the file to the workspace folder.

Set cron to 0 9 * * * (daily 9am).

Prompt Design Tips

Unlike a conversation, a scheduled prompt has to convey its intent in one shot. Claude starts from a blank session each run, so nothing carries over from last time.

Specify the output format concretely—filename pattern, save location, heading structure. Avoid vague words, too. "Past 24 hours" instead of "recent news," "maximum 5" instead of "several." Quantifying alone steadies the output.

Spell out error behavior as well. A single line like "If no search results are found, note that in the file" keeps an empty morning from leaving behind nothing but a blank file.

Use Case 2: Weekly Report Auto-Generation

A Friday-5pm task that summarizes the week's workspace changes.

Check the files in the workspace folder and list those created or
updated in the past 7 days.

Create a weekly report as a .md file:

Filename: weekly-report-{this-friday's-date}.md

# Weekly Report ({Monday} – {Friday})

## This Week's Deliverables
- New: {list}
- Updated: {list}

## Work Summary
(3-5 sentences inferring the week's main work from file contents)

## Looking to Next Week
(Bullet points of likely unfinished work or next steps)

Set cron to 0 17 * * 5 (Fridays 5pm).

Use Case 3: Reminders

A reminder built on one-time execution. Say "remind me tomorrow at 2pm" in conversation and Claude creates the one-time task for you. Internally, the fireAt parameter gets an ISO 8601 timestamp like 2026-03-20T14:00:00+09:00.

The reminder prompt can be brief.

Remind the user of the following:

Reminder: Prepare for the 3pm design review meeting
          Do a final check of the Figma prototypes

Save the reminder content to the workspace as a .md file.

Handing Over File Cleanup: Make It Reversible Before You Automate It

The three use cases above all produce text. If Claude misreads your intent, you skim the output and rewrite the prompt. Tidying a Downloads folder or archiving old files is a different animal. One bad judgment at 3am, with nobody watching, and something is gone by morning.

So for any task that moves files around, I rework it into a reversible shape before I schedule it. Three steps.

First, replace deletion with quarantine. Nothing gets removed—files get moved into a dated holding folder. If the rule was wrong, the originals are still sitting there when you look.

Second, list the candidates before touching anything. Have the task print what it intends to move and where, and read that list with your own eyes before you let it run for real.

Third, record every move, one line per file. With a source-to-destination table, undoing the run is mechanical.

Write the prompt so that inspection and execution are separate steps.

Tidy up ~/Downloads. Do not delete anything.

1. List files last modified more than 14 days ago as move candidates
2. Move each file to ~/Archive/{today's date}/
3. Record source and destination as one TSV line per file in
   ~/Archive/{today's date}/manifest.tsv
4. If a file of the same name already exists at the destination, skip it
   without overwriting and record the reason

The script behind it looks like this. It lists by default; you flip it to a real run once the output looks right.

#!/usr/bin/env bash
set -euo pipefail
 
SRC="$HOME/Downloads"
DEST="$HOME/Archive/$(date +%Y-%m-%d)"
MANIFEST="$DEST/manifest.tsv"
DRY_RUN="${DRY_RUN:-1}"   # listing only by default; DRY_RUN=0 actually moves
 
mkdir -p "$DEST"
: > "$MANIFEST"
 
find "$SRC" -maxdepth 1 -type f -mtime +14 -print0 |
while IFS= read -r -d '' f; do
  target="$DEST/$(basename "$f")"
  if [ -e "$target" ]; then
    printf '%s\t%s\tskipped-exists\n' "$f" "$target" >> "$MANIFEST"
    continue
  fi
  if [ "$DRY_RUN" = "1" ]; then
    printf '%s\t%s\twould-move\n' "$f" "$target" >> "$MANIFEST"
  else
    mv -n "$f" "$target"
    printf '%s\t%s\tmoved\n' "$f" "$target" >> "$MANIFEST"
  fi
done
 
echo "$(wc -l < "$MANIFEST") candidates (DRY_RUN=$DRY_RUN)"

-mtime +14 matches files last modified more than fourteen days ago, and mv -n refuses to overwrite an existing destination file. Because the destination is a dated folder, a second run on the same day simply fills the manifest with skipped-exists rather than scattering duplicates. Idempotency, in file work, takes the shape of never overwriting.

Undoing a run means reading the manifest backwards.

awk -F'\t' '$3=="moved" { print $2 "\t" $1 }' "$HOME/Archive/2026-03-19/manifest.tsv" |
while IFS=$'\t' read -r from to; do mv -n "$from" "$to"; done

Emptying the quarantine folder is the one step I keep by hand. Work that needs no judgment goes to the machine; work you cannot undo stays with a person. Draw that line and you can widen the automation without losing sleep over it.

Combining with MCP Connectors

Scheduled tasks open up further once you pair them with MCP connectors. With a Slack connector, the morning digest can post to a channel; with a Google Drive connector, the weekly report can append straight to a spreadsheet.

Just write "Post to the Slack #general channel" in the task prompt and the connected connector handles it. Not having to go check a screen for the output—having it land where you already look—pays off quietly in unattended operation.

Managing and Running Tasks

Recurring tasks pause and resume via the enabled flag. Stop the morning digest during a vacation, or rest the weekly report at a project milestone.

Whether completion pings your current session is controlled by notifyOnCompletion. For tasks you want running quietly in the background, switching notifications off keeps the screen calm.

Timing has one quirk. Recurring tasks get a several-minute random delay for server load balancing, so they don't fire at exactly 9:00:00—not ideal when you need second-level precision. One-time tasks have no such delay. Also, nothing runs while the Mac is asleep or the app is closed; skipped runs may fire at the next launch.

Three Lessons for Keeping Things Running Unattended

As an indie developer running several recurring tasks over a long stretch, a few lessons surfaced that you won't find in the docs—three habits that saved me more than once.

1. Stagger Run Times into Off-Peak Hours

The one that helped most was staggering the timing. Stack several recurring tasks in the same window and their work overlaps, tripping over each other. I recommend deliberately spreading run times into off-peak hours—avoiding the 7–9am commute crush, the 12–1pm lunch window, and the 6–11pm evening peak—and simply spacing jobs 30 to 45 minutes apart through the late night and early morning noticeably cut dropped runs. Once you have more than a handful of tasks, just designing when each fires buys a lot of stability.

2. Do One Manual Dry Run First

Next, I strongly recommend one manual "dry run" before scheduling. Run a new task by hand once, read the output line by line, and keep a short log of what each run changed and why. Being able to retrace your own steps later helps you avoid the worst case—something quietly breaking while no one is watching. This dry-run-and-log habit has saved me repeatedly.

3. Make It Survive Running Twice (Idempotency)

Third, write prompts so the result survives running more than once—idempotency. "Regenerate the file for today's date" beats "append to the file"; "rebuild from the current full set" beats "count and add." That way you avoid the trap where a delayed, double-fired task doubles up its output. In unattended operation, the property that running the same thing repeatedly yields the same result is what saves you.

When a Task Won't Run

If a task doesn't execute, first check that Cowork is running and the Mac isn't asleep. Confirm enabled is true, and that the cron weekday specification is what you intended (remember 0 and 7 both mean Sunday).

Prompts that are too long or too complex can stall mid-run. Give each task one clear goal and split complex processing into separate tasks—the simpler path to stability.

Your Next Step

Register just one morning digest, then read tomorrow's output line by line. If you can fold the "I should have phrased this differently" moments back into the prompt, you'll get a feel for how to expand your automation from there. Thanks for reading.

Thank You for Reading

Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.