Browse the bible
Foundations
Getting started
Capabilities
Security & governance
Workflows
Prompt library
Rollout playbook
Troubleshooting
Reference
Capabilities

Scheduled tasks — Claude Cowork on a timer

Five high-value scheduled-task patterns for Claude Cowork — Monday briefings, close trackers, inbox sweeps. The on-machine and quota constraints to plan around.

Updated 2026-04-25Read 5 min

TL;DR. Cowork can run on a timer — daily, weekly, monthly, cron-style. The five patterns below cover roughly every mid-market use case we have shipped: Monday briefings, weekly close trackers, daily inbox sweeps, monthly variance refresh, quarterly compliance pulse. Two real constraints: the laptop has to be on, and each run consumes quota.

What scheduled tasks are#

A scheduled task is a Cowork run that fires at a defined time. It reads from the workspace, executes a prompt or skill, writes to the workspace, and logs the run for audit. Functionally, it's the same Cowork session you would run manually — but with a clock instead of a human.

Schedules support recurring (every Monday at 07:00) and cron-style (every weekday at 09:00, every first business day of the month, etc.).

Five high-value patterns#

Monday briefing. Every Monday at 07:00, scan a folder for new docs, summarise, write a one-page Word brief to output/. The operator opens the brief with their first coffee instead of spending 30 minutes assembling it.

Weekly close tracker. Every Friday at 17:00, regenerate the close-progress dashboard from the live workspace. Finance walks into Monday's standup with the up-to-date picture, not the picture from when someone remembered to refresh.

Daily inbox sweep. Every weekday morning, classify the new files in inbox/, move them into the right subfolders, append a one-line summary to inbox-manifest.md. The inbox is empty by the time the team starts work.

Monthly variance refresh. First business day of the month, regenerate variance commentary using the latest actuals. The operator reviews and edits, instead of building from scratch.

Quarterly compliance pulse. Every quarter, run a compliance checklist against current documents and produce an exceptions report. Surfaces drift before it becomes an audit finding.

The on-machine constraint#

Cowork runs on the laptop. If the laptop is off or asleep, the task does not fire.

  • For occasional schedules — Monday morning briefings, monthly closes — this is fine. The operator's laptop is on at those moments.
  • For always-on workflows, the workaround is a small dedicated Mac mini in the office, or a virtual machine. Treat it as the team's "Cowork server."
  • For 24/7 critical workflows, scheduled tasks are not the right primitive. Use a server-side connector or a real automation platform; Cowork is not designed to be a cron daemon.

The quota constraint#

Each scheduled run consumes quota from the active subscription, the same way a manual run does.

  • Heavy daily runs on a Pro seat will exhaust the 5-hour quota window. Plan a Max seat for the operator who owns scheduled tasks.
  • Spread heavy runs across the day if quota becomes the bottleneck.
  • See Usage limits for the quota math.

Audit and visibility#

Treat scheduled tasks as production code, not as fire-and-forget magic.

  • Each run produces a log entry; preserve them.
  • Name tasks clearly: monday-finance-brief, not task-3.
  • Document each task: what it does, who owns it, when it runs, what to do if it fails.

The Tinkso convention is a single scheduled-tasks.md file in the workspace that lists every active task, owner, last successful run, and known failure modes. Five minutes of audit work saves an embarrassing meeting six months later.

When not to use scheduled tasks#

  • Event-driven work. "When a new file lands, do X." That is polling — close, but not real-time. If real-time matters, use a different mechanism.
  • Ad-hoc work. Anything without a stable cadence stays manual.
  • Decisions. Schedule the prep step, not the decision step. Cowork should produce the input the human will judge, not the judgment itself.

Tinkso's take#

We typically ship one or two scheduled tasks at the end of a six-week pilot — not earlier. They are a confidence signal: the team trusts Cowork enough to let it run unattended. Before that point, every run should be human-triggered.

The other reason to delay: scheduled tasks have a higher governance bar. They run when nobody is watching, so the prompt and the workspace policy have to be sturdy enough that nothing important can be quietly broken. That sturdiness usually arrives in week five or six, not before.

Try this#

Pick one weekly task that is currently a 30-minute manual prep block — the kind of work where someone says "oh, it's Monday, I need to do the X thing." Convert it to a scheduled Cowork run firing one hour before the meeting it feeds. Measure the time saved over a month. That single saved hour-per-week is usually enough to justify the next scheduled task.

Need help applying this?

Book a 30-minute call. We'll ask where you are, what your team needs, and which systems Cowork should touch.

Last reviewed: 25 April 2026 · The Cowork Bible · Tinkso