How to run a script on a schedule without a server

The script takes twenty minutes. Everything around it takes a week.

You want something to happen every morning at eight: pull yesterday's numbers, summarise them, post the summary to a channel. The code is maybe twenty lines. So why does this routinely become a multi-day job?

Because the script is the easy part.

What the script does not include

Write the twenty lines and you immediately own a list of questions the code does not answer:

• Where does it run? Your laptop is shut at eight. So: a VPS, a container, a scheduled function, or a machine that stays on.
• What triggers it? A cron entry on a box you now maintain, patch and pay for.
• Where does the API token live? Not in the repository. So: an env file, a secrets manager, or a deployment pipeline that injects it.
• What happens when the API returns 429? Nothing, unless you wrote retry logic.
• How do you find out it broke? Cron mails root by default, which nobody reads.
• How do you find out why? Only if you kept the logs somewhere durable.

Each of those is individually small and collectively the reason the job takes a week. None of them is the interesting bit, and all of them are things you keep maintaining afterwards.

The options, honestly compared

Cron on a VPS

Cheapest in cash, most expensive in attention. You own the OS, the patching, the disk filling up, and the day the box reboots and you discover the cron user's environment differs from your shell's. Fine if you already run a server for other reasons. A poor trade if this job is the only reason it exists.

A scheduled serverless function

No machine to maintain, which removes most of the list above. You still write retries, still handle secrets, still build somewhere to put logs, and you still have to notice when it stops. Good if you are comfortable in that platform's tooling and the job is genuinely bespoke.

GitHub Actions on a schedule

Popular because it is already there. Two caveats people hit: scheduled workflows are queued rather than guaranteed, so "every five minutes" can drift considerably under load, and scheduled workflows on a repository with no recent activity get disabled. It is a CI system being used as a scheduler.

A scheduled automation service

You describe the trigger and the steps; the retries, secret storage, run history and failure alerts come with it. You trade some control for not owning the list. That is the category Zymura is in, and it is worth being direct about the trade: you cannot run arbitrary code on the server, so anything genuinely custom goes through an HTTP call to something you control.

The part everyone underestimates

Not any single item on that list — the fact that the list never shrinks. Six months later the token expires, the API adds a required header, the box needs a kernel patch. The twenty-line script is still twenty lines. The scaffolding around it is what you actually maintain.

Whichever route you choose, the question worth asking early is: when this stops working, how will I find out? Not if — every integration breaks eventually. The failure mode that costs real money is the one where nothing tells you, which is the subject of the flow that ran and did nothing.

If the answer is "I'd notice the message hadn't arrived", you are relying on a human remembering the absence of something. That works for about three weeks.