Cron in Node.js: node-cron, node-schedule, and System Cron

Cron in Node.js: use node-cron for cron syntax in JS, node-schedule for flexible scheduling, or system cron for OS-level scheduling. For production, use a job queue (BullMQ, Bull) for distributed scheduling with retries and persistence - in-process cron is fragile when the process restarts.

node-cron
node-schedule
Cron syntax
System cron
Production: use a job queue
BullMQ example
Cron in K8s
FAQ

node-cron

const cron = require('node-cron');

// Run every minute
cron.schedule('* * * * *', () => {
  console.log('Running task');
});

The team that uses node-cron has cron-syntax in JS. Works in-process; lost on crash.

node-schedule

const schedule = require('node-schedule');

// Every 5 minutes
const job = schedule.scheduleJob('*/5 * * * *', () => {
  console.log('Running task');
});

// Cancel later
job.cancel();

The team that uses node-schedule has more flexibility (recurring rules, named jobs, cancellation).

Cron syntax

* * * * * *
| | | | | |
| | | | | +--- day of week (0-6, Sunday=0)
| | | | +----- month (1-12)
| | | +------- day of month (1-31)
| | +--------- hour (0-23)
| +----------- minute (0-59)
+------------- second (0-59, optional)

The team that knows the syntax writes correct schedules.

System cron

# Edit crontab
crontab -e

# Add a job
0 3 * * * /usr/bin/node /opt/myapp/script.js

Survives app restarts. The team that uses system cron has scheduled jobs independent of the app process.

Production: use a job queue

In-process cron is fragile. For production:

BullMQ (Redis-based): persistent jobs, retries, concurrency control.
Bull (older, Redis-based): similar features.
Agenda (MongoDB-based): persistent jobs with MongoDB.
Celery (Python, but works from Node): distributed task queue.

The team that uses a job queue has scheduled jobs that survive crashes, scale across workers, and have retry logic.

BullMQ example

const { Queue, Worker } = require('bullmq');

const myQueue = new Queue('myjobs', { connection: { host: 'redis' } });

// Producer
await myQueue.add('send-email', { to: '[email protected]' }, {
  repeat: { pattern: '0 3 * * *' }  // daily at 3am
});

// Worker (separate process)
const worker = new Worker('myjobs', async job => {
  await sendEmail(job.data.to);
}, { connection: { host: 'redis' } });

The team that uses BullMQ has scheduled jobs in Redis with retries, concurrency, and observability.

Cron in K8s

Use Kubernetes CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-job
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: my-job
              image: my-job:1.0
          restartPolicy: OnFailure

The team that runs in K8s uses CronJob. Native, observable, retried on failure.

FAQ

Is in-process cron reliable?

No - lost on process restart, no retries, no observability. The team that uses in-process cron for dev only, and a job queue for production, has the right split.

What’s the best library for Node cron?

node-cron for simple cron syntax. node-schedule for flexibility. BullMQ for production-grade (with Redis).

Can I use system cron in Docker?

Yes but tricky. The team that uses K8s CronJob or a job queue has better Docker-native scheduling.

How do I test cron jobs?

Run the function directly (no scheduler), or use a test scheduler that fires the job immediately. The team that tests has working code.

What’s the time zone for cron?

System local time by default. The team that runs in UTC has predictable scheduling across regions.

If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.

Useful related references: