How do you put Claude on a schedule, and what can actually trigger it?
Last updated 2026-08-18 · Overview — no new claims; each statement links to the entry that carries the primary sources.
Claude can run a task every hour, day, or week with nobody watching. Most of the work isn’t the scheduler — it’s what you encode before you schedule.
Do it by hand first, then encode it
Section titled “Do it by hand first, then encode it”The recipe I give on calls: do the task once or twice yourself, then ask Claude to encode what you just did as a prompt and schedule it. The rule of thumb for when: if you find yourself doing something three times, make it a skill — a reusable instruction folder Claude loads on its own when a task matches its description (Skills vs prompts). After each run, fold what you learned back into the file; you’re writing the skill over time, not in one sitting.
Every run is a fresh Claude
Section titled “Every run is a fresh Claude”A scheduled task doesn’t keep an assistant alive between runs. Each run spawns a new session that sees none of your past chats — only the instructions and files you left behind (Memory vs files). So the instructions file is the automation: bake decisions in as bullets the moment you make them, and prune anything that will go stale and confuse a reader who was born this morning.
Schedules only — hourly is the floor
Section titled “Schedules only — hourly is the floor”Without code, Claude runs on time cadences: hourly at most frequent, then daily, weekly, or manual. Nothing fires on “the meeting just ended” or “a Slack message arrived” (Event triggers). The bridges: an hourly task that polls the calendar or inbox and acts when something changed — up to an hour late — or, at the edge of no-code, a Claude Code routine’s API endpoint that anything able to send an HTTP POST can trigger.
Local or cloud
Section titled “Local or cloud”A run scheduled on your own machine inherits everything you set up interactively — connectors, sign-ins, saved permissions — and can go down to a one-minute interval; the catch is the machine must be on (Local scheduled runs). Cloud runs survive a closed lid but start bare: connectors reconfigured per task, hourly minimum. Agents often propose the cloud route on their own; when your machine is on anyway, push back and say which connectors already work locally.
Fence what it does unattended
Section titled “Fence what it does unattended”An unattended run plus outbound actions is where scheduling goes wrong. The two rules I set up on calls: “never send an email unless I explicitly ask” in the global instructions, and for anything watching your accounts, “always reply to me; do not do any kind of external communication.” Sends need approval by default, which a run with nobody watching can’t give (Newsletter digest) — and note that a scheduled task’s plain Slack post lands silently unless it @mentions you or hits a keyword (Slack pings).
What people actually schedule
Section titled “What people actually schedule”The recipes from calls: a 7am to-do list pulled from Asana and posted to Slack; a Monday-morning count that keeps a number nobody was tracking; a weekly digest of newsletters pooled under one Gmail label (Newsletter digest). All share the shape above — a procedure proven by hand, written down, run on a clock.
Go deeper
Section titled “Go deeper”- Event triggers — what no-code scheduling supports, and the API-endpoint workaround for real events
- Local scheduled runs — what a local run inherits, and when the cloud is actually needed
- Skills vs prompts — encoding a repeated procedure so it loads itself
- Memory vs files — why the instructions file is the automation
- Newsletter digest — a worked example, end to end
- Slack pings — making the scheduled run’s output actually notify you