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 \u2014 but only past a certain job count, and only if you size it for burst rather than idle.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Managed cron SaaS is worse for anything frequent. Most plans bundle a fixed number of runs \u2014 often 3,000 to 100,000 per month \u2014 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Memory is the sizing constraint, not CPU. A shell script doing curl or rsync needs 20\u201350 MB. A Node process with dependencies starts at 80\u2013150 MB and can spike past 300 MB on a large JSON payload. Python with pandas loading a 200 MB CSV will use 600 MB\u20131 GB during parse. Add 150\u2013250 MB for the OS and you can see where 1 GB stops being enough.<\/p>\n\n\n\n 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\u201320 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 \u2014 a nightly 5 GB dataset download is 150 GB per month.<\/p>\n\n\n\n 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.<\/p>\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Add locking with flock or a lockfile so overlapping runs cannot corrupt state \u2014 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u201360% 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.<\/p>\n\n\n\n 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 \u2014 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.<\/p>\n\n\n\n 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 \u2014 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<\/a> and filter by bandwidth allowance, which is the spec that most often decides whether a scheduler stays cheap.<\/p>\n\n\n\nOption<\/th> Monthly cost<\/th> Cost at 43,200 runs\/mo<\/th> Best for<\/th><\/tr><\/thead> Free-tier serverless cron<\/td> $0<\/td> $0\u20133 (watch timeouts)<\/td> 1\u20132 daily jobs<\/td><\/tr> Managed cron SaaS (mid tier)<\/td> $9\u2013$29<\/td> $29+ overage on runs<\/td> Non-technical teams<\/td><\/tr> VPS 1 vCPU \/ 1 GB<\/td> $3\u2013$6 flat<\/td> $3\u2013$6<\/td> Dozens of light jobs<\/td><\/tr> VPS 2 vCPU \/ 2 GB<\/td> $5\u2013$10 flat<\/td> $5\u2013$10<\/td> Concurrency, Node\/Python<\/td><\/tr> VPS 2 vCPU \/ 4 GB<\/td> $10\u2013$18 flat<\/td> $10\u2013$18<\/td> Large file parsing<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Specs That Actually Matter for a Job Runner<\/h2>\n\n\n\n
Reliability: Why a VPS Wins on Determinism<\/h2>\n\n\n\n
Best Practices for Job Hosting<\/h2>\n\n\n\n
Migration Path From a Paid Scheduler<\/h2>\n\n\n\n
When a VPS Is the Wrong Choice<\/h2>\n\n\n\n