Back to Guides
/ Guides

Claude Scheduled Tasks: How to Run Claude on a Schedule (2026)

Aleks Koha7 min read

For most of its life, Claude was something you opened. You showed up, typed, got an answer, left. Scheduled tasks flip that: you define a prompt and a cadence — every weekday at 7am, every Monday, every hour — and Claude runs it without you, delivering the result when it's done.

That's a real shift, and it's worth setting up. But there's a ceiling on what a scheduled prompt can do, and most people hit it around week two — right when their recurring task starts needing a database, an endpoint, or an output that lives somewhere other than a chat thread. This guide covers both halves: how to use Claude's native scheduling, and what to do when your schedule outgrows it.

What Claude Scheduled Tasks Are

A scheduled task is a saved prompt plus a timer. At the appointed time, Claude spins up a fresh session, works through the prompt — searching, reading connected tools, writing — and posts the result for you to find. You don't need to be at your computer; the cloud variants don't even need your computer to be on.

The obvious uses are the recurring rituals you currently rebuild by hand: a morning briefing assembled from your inbox and calendar, a Friday summary of what shipped, a competitor watch, a weekly digest of mentions. Anything that's "same prompt, new data, fixed rhythm" is a candidate.

The Three Ways to Schedule Claude

Cowork scheduled tasks (desktop). In the Claude desktop app, the Cowork tab has a Schedule section: create a task, name it, paste your prompt, pick a cadence. Available on paid Claude plans. Good for personal recurring work that reads files and connected tools.

Claude Code cloud routines. At claude.ai/code/scheduled you can schedule tasks that run on Anthropic's cloud infrastructure — your laptop can be closed, no terminal open, no cron scripts. Available on Pro, Max, Team, and Enterprise plans with Claude Code on the web enabled. This is the right home for repo-adjacent recurring work: nightly dependency checks, scheduled test runs, doc regeneration.

Claude Tag self-scheduling. If your team uses Claude Tag in Slack, Claude can schedule tasks for itself — pursuing a project over hours or days and posting updates to the channel. Enterprise and Team plans only, for now.

All three share the same shape: Claude wakes up, does the work inside its own session, and hands you the output.

What Scheduled Tasks Are Great For

The sweet spot is read-heavy, write-light work. Tasks that gather, summarize, and report:

Briefings and digests. Morning inbox summary, weekly metrics narrative, a Monday list of everything that went stale last week.

Watches. Competitor site changes, pricing moves, new reviews, keyword rankings — anything where the job is "check and tell me if something changed."

Recurring analysis. Re-run the same analysis on a fresh export every week and highlight what moved.

For all of these, the output is a message, and a message is exactly what a Claude session is built to produce.

Where Scheduled Prompts Stop

Here's the ceiling: a scheduled task runs inside a Claude session. When the session ends, everything but the message disappears. That's fine for briefings. It breaks down the moment your recurring job needs to:

Accumulate state. A price tracker is only useful if it remembers last week's prices. A session that starts fresh every run has nowhere durable to put them.

Serve an endpoint. If the output of your job should be a dashboard someone can open, a webhook another tool can call, or an API your site reads — a chat message can't be that.

Act on real infrastructure. Writing rows to a production database, pushing a file to a bucket, sending transactional email from your domain — these need provisioned, credentialed infrastructure, not a sandbox.

Run at real scale. Processing a 50,000-row CSV every night is a batch job, not a prompt.

The common workaround is to bolt a Zapier or Make scenario onto the side — but now you're maintaining a second system, and the AI is back to being one step in a pipeline you personally glue together.

The Upgrade: Build With Claude, Host on Matagi

The cleaner move: keep Claude as the builder, and give it somewhere real to deploy. Connect the Matagi MCP server to Claude — one remote endpoint, OAuth sign-in, no API keys — and Claude gains tools to provision actual infrastructure: serverless functions, isolated Postgres databases, batch jobs, deployments, and crucially, schedules that run what it builds.

The workflow looks like this. You describe the recurring job to Claude once: "Track these five competitors' pricing pages daily, store the history, and email me only when something changes." Claude — through Matagi's MCP tools — writes the function, provisions a database for the price history, registers the cron, and wires the email delivery. From then on, the job runs on Matagi's infrastructure on its schedule. No Claude session needs to wake up for it; there's nothing for you to keep open, and the state persists between runs because it lives in a real database.

The division of labor is the point: Claude is the engineer, Matagi is the machine room. Claude's native scheduled tasks are Claude showing up to do the work personally, every time. A Matagi-hosted cron is Claude building the thing once — and the thing doing the work forever after. When the job changes, you tell Claude, and it updates the deployed function.

Because the whole loop happens over MCP, "set up a nightly job with a database behind it" is a single conversation, not a DevOps project. Credentials for any external tools the job touches are injected server-side by Matagi's proxy — they never appear in the generated code. And the verify-don't-trust rule applies here as everywhere: have the job's first few runs deliver to you for review before you let it act unattended.

A Prompt to Start With

Connect the Matagi MCP server to Claude (takes about a minute — instructions here), then paste:

"Build me a scheduled job that runs every weekday at 7am. It should [describe the task: what to check, where the data comes from, what to store]. Keep a history of results in a database so runs can compare against previous ones. Deliver the output to [email/Slack]. Use Matagi to provision whatever infrastructure this needs, and show me the first run's output before enabling the schedule."

Claude will provision the pieces, run it once for your review, and enable the cron when you approve.

FAQs

Do Claude's native scheduled tasks require my computer to be on? Cowork scheduled tasks run from the desktop app. Cloud routines (claude.ai/code/scheduled) run on Anthropic's infrastructure and don't need your machine at all.

What plans include scheduled tasks? Cowork scheduling ships with paid Claude plans; cloud routines are available on Pro, Max, Team, and Enterprise with Claude Code on the web enabled.

When should I use a Matagi-hosted cron instead of a Claude scheduled task? Use Claude's native scheduling when the output is a message and no state needs to survive between runs. Use a Matagi-hosted cron when the job needs a database, an endpoint, bulk processing, or actions on real infrastructure.

Does a Matagi-hosted job still use AI at runtime? If it needs to. Functions hosted on Matagi can call every major model through the Matagi proxy — so a nightly job can summarize, classify, or draft as part of its run, without you managing API keys.

Can I see what a scheduled job did? Yes — runs are logged, and the sane default is to have the job deliver its output (or a "nothing changed" note) somewhere you'll see it.

Ready to give your scheduled tasks real infrastructure? Connect the Matagi MCP server — one URL, OAuth sign-in, and Claude can build and host the whole job. New accounts start with trial credit.

claude scheduled tasksclaudeschedulingcronai agentsmcp

Build your first AI agent free

Describe what you want done in plain English. Matagi provisions the infrastructure, wires the integrations, and deploys it.

Get started