There are three ways to run scheduled jobs in a Node.js project: in-process with node-cron (the schedule lives in the running app), OS-level with crontab -e (the schedule lives in the OS), and platform-level on the deploy (the schedule is a config the platform executes). Each pattern has a different answer to the same question: when the app restarts, does the schedule survive? In-process loses the schedule on every restart. OS-level survives the restart but loses it on container recreation. Platform-level is the right answer for production, because the platform is the one restarting the process.
This post walks through the three patterns, the overlap problem, the persistence problem, the observability problem, and the right pattern for each deploy model.
Table of contents
- The in-process pattern —
node-cronand the schedule that lives in memory - The OS-level pattern —
crontab -eand the schedule that lives on the box - The platform-level pattern — the deploy platform owns the schedule
- The overlap problem — when 5 minutes is not actually 5 minutes
- The persistence problem — when the schedule needs to survive a deploy
- The observability problem — when nobody knows if the job ran
- The right pattern for the team’s actual project
- FAQ
The in-process pattern — node-cron and the schedule that lives in memory
The OS-level pattern — crontab -e and the schedule that lives on the box
The platform-level pattern — the deploy platform owns the schedule
The overlap problem — when 5 minutes is not actually 5 minutes
The persistence problem — when the schedule needs to survive a deploy
The observability problem — when nobody knows if the job ran
The right pattern for the team’s actual project
The right pattern is the one that fits the team’s deploy model: single-process app, no deploys, no concurrency (in-process node-cron); single VM, long-running app, occasional restart (OS-level crontab); containers, managed platform, frequent deploys (platform-level cron); distributed system with multiple instances (platform-level with concurrency: 1 or an external lock service).
The schedule is a piece of the platform. The team’s mental model for the project includes the static page, the API, the database, the storage, the secret store, the logs, the rollback, and the schedule. The RunxBuild hosting calculator is the right place to do the broader exercise — pick the runtime, the worker pool, the schedule frequency, the storage, the database, and the egress, and the calculator shows what the project’s monthly infra actually costs.
Useful related references:
FAQ
What is the difference between node-cron and crontab?
node-cron is an in-process scheduler that lives inside the running Node app. crontab is the OS-level scheduler that runs commands on the box. The two have different lifecycles — node-cron’s schedule is lost on every app restart, crontab’s schedule survives a restart but is lost on container recreation.
How do I run a cron job in a Node.js project?
Three patterns: in-process with node-cron (lives in the app), OS-level with crontab -e (lives on the box), platform-level on the deploy (lives in the platform’s config). The right answer depends on the deploy model — in-process for dev, OS-level for single-VM production, platform-level for containers and managed PaaS.
How do I prevent overlapping cron runs?
Three patterns: idempotent code with a database lock, an external flock or Redis lock, or the platform’s concurrency: 1 policy. The right answer is the one that survives a restart — the platform-level lock or the external Redis lock, not the in-process lock.
How do I see the logs of a cron job?
In-process logs go to the app’s stdout (watch the app’s logs). OS-level logs go to /var/log/cron.log if redirected, or to mail. Platform-level logs go to the platform’s run history (last 100 runs, success rate, errors, duration). The right answer for production is the platform-level view.
What is the right cron pattern for a Docker container?
The platform-level pattern — configure the schedule in the platform’s spec, let the platform run the job, let the platform handle the logs and retries. The OS-level crontab inside a container is the wrong answer for a frequently-recreated container.
Can I run node-cron in a serverless function?
No. The serverless function is not always running, and cron.schedule is registered in the function’s memory. The right answer is the platform’s scheduled function trigger (AWS EventBridge, GCP Cloud Scheduler, Vercel Cron) which fires the function on the schedule.
How do I run a node script every 5 minutes?
OS-level: add */5 * * * * cd /app && /usr/bin/node /app/jobs/sync.js to the crontab. Platform-level: add a cron block with schedule: '*/5 * * * *'. In-process: cron.schedule('*/5 * * * *', () => { ... }) at app startup.
What happens to cron when the app restarts?
In-process: the schedule resets, the next tick is interval after the restart. OS-level: the schedule survives. Platform-level: the schedule survives, the platform re-runs the next tick after the restart.