Scheduled Tasks and Automations with Claude

The honest starting point: Claude chat has no built-in scheduler

Plainly stated: if you open the Claude chat app, there is no built-in scheduler that will run a task for you at 9am every Monday. You cannot ask the chat app to wake up on its own, check something, and send you a result later. Anyone telling you otherwise is describing a different setup. The real pattern for scheduled work with Claude is a combination: Claude does the thinking and the writing, and your computer's own scheduler decides when that work runs.

That combination works well, once the two roles are clear. The scheduler, such as cron on Mac and Linux or Task Scheduler on Windows, starts a job at a set time. The job itself runs Claude Code or a small script that calls the Claude API, does the task, and saves or sends the result. Claude never schedules anything; the scheduler never writes anything. Keeping those roles separate is what makes the setup reliable and easy to debug.

Pick one small, safe automation first

Start with a task that is read-only and low risk: a weekly summary of a file you maintain, a daily digest of notes you wrote, or a Monday-morning brief built from documents you already own. A read-only task cannot accidentally change, delete, or send anything if it goes wrong, which makes it the right first automation while you learn the setup.

Write the task down as a single sentence with its inputs and its output. For example: every weekday at 8am, read yesterday's notes file and write a five-bullet summary to a dated file. That sentence already contains the schedule, the input, the job, and the output, which is everything you need to build it.

What Claude does and what the scheduler does

Claude's job is the content work: read the input, summarise it, draft it, check it against a brief, or transform it into a new format. The scheduler's job is timing and launching: run this command at this time, on this machine, whether or not you are sitting at it. When a run fails, that split tells you where to look. If the output is wrong, the prompt or the input is the problem. If nothing ran at all, the schedule or the command is the problem.

This split also explains the main limitation: the machine must be on and able to run the job at the scheduled time. A laptop that is asleep or switched off will not run a cron job. For tasks that must run regardless, the job needs to live on a machine that stays on, such as a small server, rather than a laptop you close at night.

You are writing a Monday-morning brief. Read the notes file I give you and produce: (1) the three most important items from last week, (2) any deadlines in the next seven days, (3) one suggested priority for this week. Keep it under 200 words. Do not invent dates or items that are not in the notes.

A basic setup, step by step

1. Write the prompt and test it by hand first. Run it yourself a few times and check the output before anything is automated.
2. Put the prompt and the command that runs it into a small script file, so the scheduled job runs exactly what you tested.
3. Make the script save its output to a dated file, and write errors to a separate log file, so every run leaves a trace.
4. Add the schedule: a cron entry on Mac or Linux, or a scheduled task on Windows, pointing at that script.
5. Watch the first few scheduled runs yourself and compare them with your manual runs before trusting the automation.

A typical cron entry runs a script on weekdays at 8am, and the exact form depends on your system, so check your system's scheduler documentation for the syntax. Keep the script simple: one job, one input, one output file. Complexity is where scheduled jobs quietly break.

Logging and failure handling

Every automated job should leave evidence. Save the output with the date in the filename, and log errors separately. When a run produces nothing, the log tells you whether the job never started, the input was missing, or the Claude step failed. Without logs, a silent failure can go unnoticed for weeks.

Build in a simple check: if the input file is missing or empty, the script should log that and stop, rather than asking Claude to summarise nothing and producing a confident-sounding brief from no data. Guards like that are the difference between an automation you trust and one you have to keep checking.

What not to automate yet

Do not automate actions with real consequences until the read-only version has run reliably: sending emails to clients, publishing posts, changing files in a live system, or spending money. For those, keep a human approval step in the loop. The automation can draft the email or the post, and you approve and send it. That keeps the time saving while keeping the decision with you.

Check current plans and features before building around any particular Claude tool, because offerings change. The scheduler pattern itself is stable: it relies on your operating system's scheduler and on Claude Code or the API, not on a chat feature that may or may not exist.

Frequently asked questions