Claude Code on Linux: cron vs Routines vs systemd timers (UK indie hacker decision matrix, 2026)

You have a working claude -p script, a sensible prompt, and a clear daily job. The question is what fires it at 06:55 every morning, what catches it when it falls over, and what stops the bill spiralling. In 2026 there are three credible answers on Linux: classic POSIX cron, Anthropic Routines (the cloud-hosted scheduler that launched on 14 April), and systemd timers. This post is the decision matrix, the GBP cost of each, and the sensible default for a UK indie hacker who wants the job to actually run.

The three options, in plain English

POSIX cron. Born in 1975, still in the box. Edit a crontab, save it, the daemon picks up your schedule. Free. Local. Dies when the laptop closes. No built-in retry, no native logging beyond redirecting stdout to a file, no failure notification. The reliability ceiling is your own discipline.

Anthropic Routines. Anthropic shipped Routines on 14 April 2026 as a cloud-hosted scheduler for Claude Code jobs. You define the schedule in the Anthropic console, the job runs on Anthropic infrastructure, output and logs are stored against your account. Intelligent retry on transient failures, survives whatever your laptop is doing. From 15 June 2026 the spend draws from Pool B, the new programmatic credit pool capped at your subscription price (covered in detail in the credit split guide).

systemd timers. The modern Linux scheduling primitive. Two files per job - a .service unit that describes what to run and a .timer unit that says when. Daemon-managed by systemd, logs to journalctl, supports OnFailure= handlers, runs as a service with a clear lifecycle. Free. Local. Same laptop-close limitation as cron, but materially better observability and recovery.

The decision matrix

The shape of the choice, with the numbers a UK indie hacker actually cares about. All GBP figures are 2026.

Dimension	Cron	Anthropic Routines	systemd timers
Monthly cost (scheduler)	GBP 0	Pool B usage (capped at plan)	GBP 0
Where the job runs	Your box	Anthropic cloud	Your box
Survives laptop close	No	Yes	No (unless VPS)
Retry on failure	No	Intelligent, configurable	Configurable via Restart=
Native logging	stdout redirect to file	Anthropic console	journalctl
Failure notification	None	Email / webhook	OnFailure handler unit
Setup time	2 minutes	5 minutes (console)	10 minutes (two files)
Environment isolation	Shell-level	Per-routine	EnvironmentFile per service
Concurrent run protection	None	Yes	RuntimeMaxSec, locking unit
Observability	Manual	Console dashboard	journalctl + systemctl status

Two things jump out. First, cron is the cheapest scheduler but the most expensive failure mode - a job that silently stops running for a week and nobody notices is the worst possible outcome for an agent. Second, Routines is the only option that survives laptop close without you running a server somewhere. If you do not have a VPS (and the Hetzner VPS guide lays out the GBP 3.30/mo end of the curve), Routines is doing real work for the Pool B spend.

A worked example: the 06:55 morning brief, three ways

The same job - a claude -p invocation that reads a prompt file, summarises overnight Gmail, posts to Slack - scheduled at 06:55 every weekday. Here is what each option looks like end to end.

Cron

A single crontab line:

55 6 * * 1-5 /usr/local/bin/claude -p < /home/tim/prompts/brief.md >> /var/log/brief.log 2>&1

That is it. Save the crontab, the cron daemon picks it up. If claude is not on PATH for the cron environment (it usually is not), you need the full path. If the box is asleep at 06:55, the job does not run and there is no record that it did not. If the job fails, the failure goes into /var/log/brief.log and you discover it when you grep the file in three weeks.

Suitable for: a hobby script on a Raspberry Pi that always-on, where missing a day does not matter.

Anthropic Routines

In the Anthropic console, create a Routine, paste the prompt, set the schedule to 0 55 6 * * 1-5, pick the model. Save. Done.

The job runs on Anthropic infrastructure. Output appears in the console with the full session log, token spend, and any tool calls. Retry on transient errors is automatic. You can wire a webhook to ping Slack when a run fails. The cost lands in Pool B, itemised on your bill from 15 June.

Suitable for: any job that must survive laptop close without you renting a server. UK indie hackers who close their laptop at 11pm and want a brief at 06:55 are the canonical case.

systemd timers

Two files. First, /etc/systemd/system/morning-brief.service:

[Unit]
Description=Claude Code morning brief
After=network-online.target

[Service]
Type=oneshot
User=tim
EnvironmentFile=/etc/claude/morning-brief.env
WorkingDirectory=/home/tim/prompts
ExecStart=/usr/local/bin/claude -p --input-file brief.md
StandardOutput=journal
StandardError=journal
OnFailure=notify-failure@%n.service

Then /etc/systemd/system/morning-brief.timer:

[Unit]
Description=Trigger Claude Code morning brief at 06:55 weekdays

[Timer]
OnCalendar=Mon-Fri 06:55
Persistent=true
RandomizedDelaySec=30

[Install]
WantedBy=timers.target

Enable both: sudo systemctl enable --now morning-brief.timer. Logs flow into journalctl -u morning-brief. The Persistent=true flag means if the box was off at 06:55, the job runs as soon as the box comes back up - cron will not do this. The OnFailure= line triggers a notify unit that can post to Slack or email. The EnvironmentFile= keeps the API key out of the service file and out of journalctl logs.

Suitable for: anything running on a Linux box you control that you want to actually rely on. The two-file pattern feels heavier than a cron line but the payoff (persistence, observability, failure handling) is the entire point.

The cost line: what each option actually bills

Cron and systemd timers are free schedulers. The cost is whatever claude -p itself burns, drawn from Pool B from 15 June. So a daily Sonnet job at ~5k tokens costs around 3p per run, or roughly GBP 0.90 a month on top of your subscription. The scheduler itself is free.

Routines bills the same claude -p cost - the Routine is a thin wrapper around the same model call - and the scheduler is included. There is no separate "Routines fee". The whole spend lands in Pool B and is capped at your subscription price. A UK indie hacker on the Pro plan at GBP 20 a month gets up to GBP 20 of combined SDK and Routines spend included, fail-closed by default beyond that.

The honest comparison: for a single daily brief, the three options cost the same in Anthropic terms. The differentiator is the cost of the infrastructure underneath. Cron and systemd on your laptop are free but die when you close the lid. systemd on a Hetzner VPS is GBP 3.30 a month for an always-on box that survives anything. Routines is GBP 0 of infrastructure because Anthropic runs it.

The right way to think about it: pick the infrastructure first (do I have an always-on box, or am I happy to let Anthropic run this for me?), then the scheduler falls out. Always-on Linux box - systemd timers. No always-on box - Routines.

When cron is still the right answer

Cron earns its place in one specific case: a throwaway hobby script on a box that is always on, where missing a day does not matter and you genuinely will not notice. A daily backup of a personal notes folder. A weekly pull of public stats data. The reliability ceiling is fine because the consequence of failure is "I run it manually tomorrow".

The moment the consequence of failure is "a client did not get their report" or "the agent stopped pulling data for the dashboard and we found out a week later", cron is the wrong tool. The lack of OnFailure is the killer.

When Routines wins

Three cases where Routines is the clear pick.

Laptop close persistence without a VPS. You work on a laptop, you close it at 11pm, you want a job at 06:55. Without a VPS or always-on machine, Routines is the only option that runs.

You want one place to see all agent runs. The Anthropic console dashboard shows every Routine run, every token, every cost. If you are running five or six agents and want a single pane of glass, Routines is built for that view. systemd journalctl is per-box; Routines is per-account.

Cost visibility for the 15 June split. Pool B is going to be the most-watched line on every UK indie hacker's Anthropic bill from June. Routines is itemised by name in the console. Per-Routine spend is the easiest way to answer "is this agent worth its monthly cost?"

The honest downside is the Pool B cost eats into your subscription cap. If you are running a heavy schedule (a Routine every fifteen minutes), the spend stacks. The fix is per-key isolation in the console (covered in the credit split guide) and dropping the heavier jobs to Sonnet from Opus where the prompt allows.

When systemd timers win

Anywhere you have a Linux box you control and want the job to actually run reliably. That is most production indie hacker setups.

The killer features in 2026:

• OnFailure= wires a second unit to run automatically when the job fails. Pipe it to Slack and you get failure alerts within seconds with the journalctl context attached.
• Persistent=true means a missed run (box was off, network was down) fires as soon as the box recovers. Cron just skips it.
• RandomizedDelaySec= jitters a fleet of jobs so they do not all hit the API at the same second, helping with rate-limit friendliness.
• EnvironmentFile= keeps secrets out of the unit file and out of journalctl, with proper file permissions on the env file (chmod 600).
• journalctl -u <unit> --since today gives you the full run output, structured by unit, queryable. No log file management, no rotation scripts.

The two-file overhead is real but it is twenty minutes once per job. Compared to debugging a cron job that silently stopped firing because the user shell environment differed from the cron environment, it is a bargain.

The UK indie hacker default

The recommendation, after running all three across half a dozen production agents this year:

• systemd timers as the default for any Linux box you own (laptop with caveats, dedicated dev box, or the Hetzner VPS at GBP 3.30/mo).
• Anthropic Routines for any job that must survive laptop close and where you do not want to run a server. Honest about the Pool B cost from 15 June - this is the trade for the convenience.
• Cron only for hobby scripts where the consequence of failure is "I run it manually tomorrow".

The pattern that ships in 2026: rent a GBP 3.30 Hetzner ARM box, install Claude Code on it, run your production agents under systemd timers with OnFailure handlers wired to Slack. Use Routines for the handful of jobs where the cloud-hosted scheduler is genuinely the right tool (typically the ones tied to your personal accounts that you do not want on a server). Cron stays in the toolbox for the truly trivial.

You can wire all three on the same machine without conflict. The exercise is matching each scheduled task to the right tool, not picking one tool for everything. Spend twenty minutes mapping your scheduled Claude jobs to columns in the decision matrix above and you will end up with a setup that survives laptop close, recovers from failure, and tells you when something went wrong - for the price of one cheap VPS and a Pro plan.

---

New here? IdeaStack publishes one deeply researched UK business opportunity every Thursday - real keyword data, competitor analysis, builder prompts. See the latest free report.