Where it runs when your laptop is shut

The options, with real numbers

A small server with a timer. A basic instance from Hetzner, DigitalOcean, Contabo or similar runs at roughly four to six dollars a month. Add a systemd timer:

[Timer]
OnCalendar=Mon *-*-* 06:00:00
Persistent=true

journalctl -u yourjob gives you logs with no additional tooling. This is the simplest thing that is yours, and it is a perfectly respectable answer for a long time.

GitHub Actions on a schedule. Free minutes on public repositories, five-minute minimum granularity, no server to maintain. Three caveats worth knowing before you rely on it: runs at popular times are delayed by minutes, scheduled workflows are disabled after roughly 60 days without repository activity, and a job needing secrets and network access is a strange place to put business logic. Fine for a daily report; wrong for anything time-critical.

Serverless with a timer: Cloudflare Workers cron triggers, a Lambda behind a scheduled event, a platform’s cron feature. Very cheap, nothing to patch. Check the limits carefully: platforms cap CPU time, wall-clock time or both, and an agent that waits four minutes on HTTP calls may be fine on one platform and impossible on another. Read the specific numbers before you design for it.

A container on a managed platform (Fly, Render, Railway, Cloud Run) when the work is long-running or holds a queue worker open.

The visual tool’s own cloud. You pay so that you run nothing. Entirely reasonable if the automation is small and the alternative is a server nobody wants to own.

The three questions that decide it

1. How long does one run take? Past about fifteen minutes, most serverless options are out.
2. Does it hold state, or need a queue worker running continuously? If yes, you want a container or a server.
3. Who else can restart it? A cron job on your laptop is a single point of failure with a name, and the name is yours.

The environment trap

This one costs teams weeks, and the mechanism is unglamorous.

Cron runs with almost no environment. No profile is sourced. PATH is typically just /usr/bin:/bin. Variables you exported in .bashrc, .zshrc or .zprofile are absent, so a script that works perfectly when you run it by hand fails under cron with a message about a missing key or a command not found.

The same applies to CI runners, to systemd services and to stdio subprocesses. All of them get the environment their parent gives them, and none of them get yours.

The fixes are boring and reliable: absolute paths to every binary, an explicit EnvironmentFile= for systemd, secrets loaded from a file or a secret store rather than assumed, and a first line in the script that fails loudly if a required variable is missing. That last one turns a silent Tuesday-morning mystery into an error message.

Time zones

Cron runs in the server’s timezone, which is usually UTC and occasionally something a previous engineer chose. Set it explicitly (CRON_TZ= in the crontab, or the timer’s own setting) and be aware that a job scheduled at 02:30 local time does not run on the day the clocks move forward. Schedule anything critical in UTC.

Secrets

Not in the repository, not in the code, not in the crontab line. Environment file with restrictive permissions at minimum, a secret store at best, and rotate them on a schedule you keep.