# How to run Claude Code on a schedule

> Four ways to make a Claude Code job run every morning without you: cron on your machine, GitHub Actions, a server, or a workflow platform, and when each one fits.

- Published: 2026-10-26
- URL: https://teton.so/guides/run-claude-code-on-a-schedule

To run Claude Code on a schedule, you either re-run a prompt headlessly with `claude -p` from a scheduler (cron, GitHub Actions, a server), or you have Claude turn the job into a script and run that script on a schedule. Re-running the prompt is the quickest to set up. Running the script Claude wrote is more predictable, cheaper per run, and easier to audit once the job touches your CRM or posts to your team.

Below are the four common setups, what each one costs you, and how to choose.

## 1. Cron on your own machine

Claude Code has a non-interactive mode: `claude -p "<prompt>"` runs one turn and prints the result. Put it in your crontab and it runs on a schedule:

```bash
# Weekdays at 7:00: summarize yesterday's pipeline changes
0 7 * * 1-5 cd ~/revops && claude -p "Compare today's HubSpot pipeline with yesterday's snapshot and post what moved to #revenue" --allowedTools "Bash(curl:*)" >> ~/revops/cron.log 2>&1
```

`--allowedTools` limits what Claude may do without asking, which matters because nobody is there to approve a tool call.

**Good for:** trying an idea for a few days.

**The catch:** it only runs while your computer is awake, the API keys live on your laptop, and nobody else on the team can see it ran or what it did.

## 2. GitHub Actions on a schedule

A GitHub Actions workflow with a `schedule` trigger runs in GitHub's cloud. Anthropic's `claude-code-action` runs Claude Code inside the job:

```yaml
name: pipeline-changes
on:
  schedule:
    - cron: "0 11 * * 1-5" # 07:00 New York, in UTC
jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Compare today's HubSpot pipeline with yesterday's snapshot and post what moved to #revenue"
```

**Good for:** jobs that belong to a code repository, such as triaging issues or updating docs.

**The catch:** scheduled runs can start late when GitHub is busy, cron is in UTC, and there is nowhere built in to keep yesterday's data, so "compare with yesterday" needs a database you set up yourself. In public repositories, GitHub turns scheduled workflows off after 60 days without repository activity.

## 3. A server you run

A small VPS with cron is option 1 without the laptop: it stays on. You also take on the server, its updates, secrets management and logs. It makes sense if you already run infrastructure and want everything there.

## 4. A workflow platform built for Claude-written jobs

The setups above re-run the prompt every time. Claude plans the job from scratch on each run, so the steps can differ from day to day, and every run pays for that planning.

The other approach is to do the job once with Claude, get the output right, and then have Claude write the steps it worked out into a script. The script runs the same way every time and calls Claude only where judgment is needed, such as summarizing a change or scoring a lead.

[Teton](https://teton.so) is built for this. In Claude Code you type `/teton`, and Claude writes the job up as one workflow file: the trigger (a schedule or a webhook), the steps, and the credentials it needs. Deploying it makes it live in the cloud. Then:

- Credentials are entered once in the dashboard, never in the chat or the file, and only reach the API hosts the workflow declares.
- Every workspace has a Postgres database, so a job can keep yesterday's snapshot and compare against it.
- Every run is recorded with its result and cost, and when a job writes to your CRM, the run lists which records it changed.
- Every version is kept, so a bad change can be rolled back in one click.

**Good for:** recurring business jobs that touch shared systems (HubSpot, Salesforce, Slack) and that the team needs to trust.

## How to choose

| | Runs without your laptop | Same steps every run | Remembers between runs | Team can see runs and changes |
| --- | --- | --- | --- | --- |
| Cron + `claude -p` on your machine | No | No | Only local files | No |
| GitHub Actions | Yes | No | Not built in | Run logs only |
| Your own server | Yes | Depends on you | If you add a database | If you build it |
| Teton | Yes | Yes | Postgres per workspace | Yes, with records changed |

A practical path: prototype with `claude -p` on your machine for a day or two, and once the output is what you want, make it permanent with a script on a platform that runs it for you.

## FAQ

### Can Claude Code run without me approving each step?

Yes. In print mode (`claude -p`) you decide up front which tools it may use with `--allowedTools`. Keep that list as narrow as the job allows, since nobody reviews the run as it happens.

### Do I have to rewrite the job by hand to make it a script?

No. Ask Claude to write the steps it took into a script. With Teton, `/teton` does this and produces one workflow file you can read before deploying.

### How do I handle API keys for a scheduled job?

Don't put them in the prompt or the script. Use the scheduler's secret store (GitHub Actions secrets, your server's environment) or, on Teton, the credentials page, which sends each key only to the hosts the workflow declares.

### What does a scheduled Claude job cost?

Re-running a prompt pays for Claude's planning and tool calls on every run. A script that calls Claude only for the judgment steps is usually much cheaper per run, and the cost is easier to predict.

---

- [All guides](https://teton.so/guides)
- [Teton](https://teton.so): the cloud for Claude Code. Build a workflow with Claude once and Teton runs it on a schedule or a webhook.