Scheduled jobs are the quiet workhorse of every automation stack: nightly backups, report generation, API polling, cache warming, price scraping, newsletter sends. Managed schedulers charge per execution, and those micro-fees compound quickly when a job runs every minute. A small VPS running cron often costs less per month than a busy job costs per week — but only past a certain job count, and only if you size it for burst rather than idle.
This is a pricing and sizing analysis, not a tutorial. It compares per-run schedulers against flat-rate servers with worked numbers, identifies the break-even point, and covers the failure modes that make cheap job runners silently miss runs.
What Per-Run Scheduling Actually Costs
Serverless schedulers look free at low volume and get expensive at high frequency. A job running every minute is 43,200 invocations per month; at $0.20 per million invocations plus compute time, the invocation fee is trivial, but a 30-second job at 256 MB consumes about 1.5 GB-hours per day. Multiply that across a dozen jobs and the free tier disappears.
Managed cron SaaS is worse for anything frequent. Most plans bundle a fixed number of runs — often 3,000 to 100,000 per month — and a minute-level job blows through a mid-tier plan in under a day. You end up paying for the schedule’s frequency, not for the work done, which is the opposite of what you want when each run takes 400 ms.
| Option | Monthly cost | Cost at 43,200 runs/mo | Best for |
|---|---|---|---|
| Free-tier serverless cron | $0 | $0–3 (watch timeouts) | 1–2 daily jobs |
| Managed cron SaaS (mid tier) | $9–$29 | $29+ overage on runs | Non-technical teams |
| VPS 1 vCPU / 1 GB | $3–$6 flat | $3–$6 | Dozens of light jobs |
| VPS 2 vCPU / 2 GB | $5–$10 flat | $5–$10 | Concurrency, Node/Python |
| VPS 2 vCPU / 4 GB | $10–$18 flat | $10–$18 | Large file parsing |
The break-even typically falls at three to five active jobs, or at any single job running more often than every 15 minutes. Past that, a flat-rate VPS is cheaper than almost any elastic scheduler, and you stop reasoning about per-execution cost entirely.
Specs That Actually Matter for a Job Runner
Job runners are bursty. They sit at 2% CPU for 59 minutes and then use a full core for 30 seconds. That pattern interacts badly with CPU credit models: a credit-throttled instance can have its burst capacity exhausted by the time a long report job runs, and the job gets starved to a fraction of a core. Check whether the plan gives a real vCPU slice or a burst-only allocation.
Memory is the sizing constraint, not CPU. A shell script doing curl or rsync needs 20–50 MB. A Node process with dependencies starts at 80–150 MB and can spike past 300 MB on a large JSON payload. Python with pandas loading a 200 MB CSV will use 600 MB–1 GB during parse. Add 150–250 MB for the OS and you can see where 1 GB stops being enough.
Disk is the third factor, and it fails quietly. Logs without rotation, cached API responses, and intermediate files from multi-step ETL jobs accumulate. A 10–20 GB disk is enough for a disciplined runner with logrotate; it is not enough for one that writes a daily 2 GB export and never deletes it. Bandwidth matters if jobs move data — a nightly 5 GB dataset download is 150 GB per month.
Reliability: Why a VPS Wins on Determinism
Elastic schedulers silently skip runs during platform incidents, throttle bursty jobs, and impose execution timeouts. A job that needs 40 minutes to back up a database cannot run on a platform that kills it at 15. On a VPS you own the clock: systemd timers fire exactly when scheduled, run for as long as needed, and write to journald where you can read the history.
For anything business-critical, determinism beats cleverness. A backup job that runs 364 nights out of 365 is worth more than an elegant serverless pipeline that silently skips the night the disk filled.
Best Practices for Job Hosting
Prefer systemd timers over classic cron. You get built-in logging via journald, retry and dependency semantics, randomised start delays to avoid thundering herds, and persistent timers that catch up after a reboot. A typical unit pairs a service file with a timer file; migration from a crontab line takes a few minutes per job.
Add locking with flock or a lockfile so overlapping runs cannot corrupt state — the single most common cause of duplicate posts and double-charged API calls. Log to a file with rotation, or to journald with a size cap. Alert on failure with a webhook or email so silence never masks a dead job, and send a heartbeat to a free uptime monitor so you notice if the runner itself goes down.
Keep secrets out of scripts: use environment files with 600 permissions or a systemd EnvironmentFile directive, never hardcoded API keys in a shell script that gets rsync’d around. Add strict bash options so a failed step aborts the job instead of continuing with stale data.
Migration Path From a Paid Scheduler
Moving jobs is low-risk because each one is self-contained. Set up the server, copy the scripts, recreate the schedules as systemd timers, and run both runners in parallel for a week. Compare outputs line by line, then retire the paid scheduler. If a job writes to an external API, use a dry-run flag first so you never double-post while testing.
Watch the first renewal. The flat-rate advantage only holds if the provider does not creep its price; budget hosts often quote an introductory rate and renew 30–60% higher. Check the renewal rate before you commit, and confirm the bandwidth allowance covers what jobs actually move. Sizing the transfer allowance is as important as sizing the CPU.
Once you own the runner, expansion is nearly free. The same VPS can host a webhook receiver that triggers jobs on demand, a queue worker, and a small status dashboard — features that would each be a separate line item on a SaaS bill. Containerise jobs with Docker and new automation gets added without touching existing ones.
When a VPS Is the Wrong Choice
If you have one or two occasional jobs, a serverless scheduler or a free-tier function is genuinely cheaper and lower-maintenance: you pay nothing for idle time and own no server. A VPS wins only once job count, frequency, or execution length grows past the elastic services’ sweet spot — or when jobs need more than a few minutes of runtime, guaranteed execution, or access to a private network. If you are still choosing a host, start from the budget VPS homepage comparison and filter by bandwidth allowance, which is the spec that most often decides whether a scheduler stays cheap.
For the middle ground — five to fifty jobs, at least one running frequently — a flat $3–6 plan with systemd timers, locking, and alerting is the lowest-cost reliable option. Job runners care about steady uptime and predictable disk I/O far more than raw CPU, so pick on provider reliability rather than core count. The budget VPS hosts on our comparison table are ranked on uptime history and three-year cost, which is the lens that matters for an always-on scheduler.
