cron vs node-schedule vs node-cron vs agenda vs later
Job Scheduling Libraries in Node.js
cronnode-schedulenode-cronagendalaterSimilar Packages:
Job Scheduling Libraries in Node.js

agenda, cron, later, node-cron, and node-schedule are all Node.js libraries designed to schedule and execute tasks at specific times or intervals. These packages help developers automate background jobs, recurring operations, or time-based workflows without relying on external systems like cron daemons. While they share the common goal of time-based task execution, they differ significantly in architecture, persistence, syntax, and use cases — ranging from simple in-memory timers to database-backed job queues with retry logic and concurrency control.

Npm Package Weekly Downloads Trend
3 Years
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
cron4,130,1538,888161 kB192 months agoMIT
node-schedule3,269,2719,22635 kB1713 years agoMIT
node-cron2,131,1483,216221 kB277 months agoISC
agenda147,7299,615276 kB12 days agoMIT
later34,0892,420-9810 years agoMIT

Job Scheduling in Node.js: agenda vs cron vs later vs node-cron vs node-schedule

Scheduling tasks in Node.js seems simple at first — just use setTimeout or setInterval, right? But real-world apps often need more: cron-like expressions, job persistence, error recovery, or complex recurrence rules. That’s where dedicated scheduling libraries come in. Let’s compare five popular options to see which fits your architecture.

🗃️ Persistence & Reliability: In-Memory vs Database-Backed

Only agenda stores jobs in a database (MongoDB). All others run entirely in memory, meaning scheduled jobs vanish if your process crashes or restarts.

agenda uses MongoDB to track job status, retries, and next run times. This makes it suitable for critical background work like sending emails or processing payments.

// agenda: Jobs survive restarts
const agenda = new Agenda({ db: { address: 'mongodb://localhost/jobs' } });

agenda.define('send email', async (job) => {
  await sendEmail(job.attrs.data.to);
});

await agenda.start();
agenda.schedule('in 10 minutes', 'send email', { to: 'user@example.com' });

In contrast, cron, node-cron, node-schedule, and later keep schedules in memory only:

// cron: Lost on restart
const CronJob = require('cron').CronJob;
new CronJob('0 */5 * * * *', () => {
  console.log('Runs every 5 minutes — but not if server restarted');
}, null, true);

// node-cron
const cron = require('node-cron');
cron.schedule('*/5 * * * *', () => {
  console.log('Same limitation');
});

// node-schedule
const schedule = require('node-schedule');
schedule.scheduleJob('*/5 * * * *', () => {
  console.log('Also in-memory only');
});

// later: doesn't run jobs at all — just calculates times
const later = require('later');
later.parse.recur().every(5).minute(); // returns a schedule object

💡 If your app can’t afford to lose scheduled work, agenda is the only option here. Otherwise, in-memory schedulers are fine for non-critical tasks.

⏱️ Syntax & Expressiveness: Cron Strings vs Natural Language

All libraries support cron-style expressions, but with key differences in precision and flexibility.

cron, node-cron, and node-schedule accept standard cron strings (5 or 6 fields). node-cron and cron support a 6th field for seconds:

// cron (6 fields: seconds optional)
new CronJob('10 * * * * *', fn); // every minute at 10 seconds

// node-cron (6 fields required)
nodeCron.schedule('10 * * * * *', fn);

// node-schedule (5 fields by default, but supports seconds via object)
schedule.scheduleJob({ hour: 10, minute: 30, second: 0 }, fn);

later stands out by offering a fluent API for building complex schedules:

// later: Every weekday at 9:30 AM
const sched = later.parse.text('at 9:30am on weekdays');
// Or programmatically
const sched = later.parse.recur().on(9, 30).time().onWeekday();

However, later doesn’t execute jobs — you must use setTimeout or similar with its output:

const next = later.schedule(sched).next(1);
setTimeout(fn, next.getTime() - Date.now());

agenda supports both cron strings and human-readable text (via human-interval):

agenda.schedule('tomorrow at 4pm', 'task');
agenda.schedule('*/5 * * * *', 'task');

🔁 Job Execution Model: Callbacks, Promises, and Concurrency

agenda is the only library that manages job concurrency, retries, and failure handling:

agenda.define('process file', { concurrency: 5, retry: true }, async (job) => {
  // Agenda handles errors, retries, and limits concurrent jobs
});

The others execute jobs as plain functions with no built-in error isolation:

// cron
new CronJob('* * * * * *', () => {
  throw new Error('Crashes the whole process!');
});

// node-cron
cron.schedule('* * * * * *', () => {
  // Unhandled rejections may terminate the process
});

// node-schedule
schedule.scheduleJob('* * * * *', () => {
  // Same risk
});

You must wrap job logic in try/catch or .catch() when using non-agenda libraries to prevent crashes.

🧩 Real-World Use Cases

Case 1: Sending Daily Reports

You need to email a report every day at 8 AM, even if the server restarts overnight.

  • Best choice: agenda — persistent, retryable, and survives restarts.
  • ❌ Others: Jobs disappear on restart; no guarantee delivery.

Case 2: Polling an External API Every 30 Seconds

A short-lived script that fetches data repeatedly while running.

  • Best choice: node-cron or cron — lightweight, second-level precision.
  • agenda: Overkill; requires MongoDB.
  • later: Doesn’t run jobs.

Case 3: Running a Cleanup Task on the Last Friday of Each Month

Complex recurrence rule needed.

  • Best choice: later + setTimeout for schedule definition, or agenda if persistence matters.
  • cron/node-cron: Can’t express "last Friday" easily in cron syntax.

Case 4: One-Time Notification in 2 Hours

Schedule a single future action.

  • Best choice: node-schedule — clean support for one-off jobs:
    schedule.scheduleJob(new Date(Date.now() + 7200000), fn);
    
  • ✅ Also works in agenda, but heavier.
  • cron/node-cron: Designed for recurring jobs; awkward for one-time.

🚫 Deprecated or Problematic?

As of 2024, none of these packages are officially deprecated. However:

  • later hasn’t seen significant updates in years and is best viewed as a schedule parser, not a job runner.
  • cron and node-cron are both actively maintained but serve nearly identical purposes — prefer node-cron for its cleaner API and explicit second support.
  • agenda remains the go-to for persistent job queues but ties you to MongoDB.
  • node-schedule is stable and widely used for in-memory scheduling with flexible input formats.

📊 Summary Table

Featureagendacronlaternode-cronnode-schedule
Persistence✅ MongoDB
Cron Syntax✅ (5/6 fields)❌ (custom)✅ (6 fields)✅ (5 fields)
Human-Readable✅ (limited)
One-Time Jobs⚠️ (awkward)✅ (with DIY)⚠️
Concurrency Control
Error Handling✅ Built-in❌ Manual❌ N/A❌ Manual❌ Manual
External DepsMongoDBNoneNoneNoneNone

💡 Final Recommendation

  • Need reliability and persistence? → agenda
  • Need simple, recurring in-memory jobs? → node-cron (or cron if you prefer it)
  • Need complex recurrence rules? → later (as a helper) + your own runner, or agenda if persistent
  • Need flexible one-time or recurring jobs without deps? → node-schedule

Choose based on whether your jobs can afford to disappear — if yes, keep it simple; if no, go with agenda.

How to Choose: cron vs node-schedule vs node-cron vs agenda vs later
  • cron:

    Choose cron if you want a minimal, battle-tested library that mimics Unix cron syntax and runs jobs in memory. It’s well-suited for simple, recurring tasks in long-running processes where persistence isn’t required. Its clean API and support for second-level precision make it a solid choice for basic scheduling needs without external dependencies.

  • node-schedule:

    Choose node-schedule if you need flexible scheduling using either cron-style strings or JavaScript Date objects, and want built-in support for one-time and recurring jobs without external storage. It’s a good middle ground for applications that require more expressiveness than basic intervals but don’t justify a full job queue system.

  • node-cron:

    Choose node-cron if you prefer a straightforward, cron-like syntax with second-level granularity and don’t need job persistence. It’s similar to cron but offers a slightly more modern API and active maintenance. Ideal for internal tooling, scripts, or services where jobs can be lost on process restart and that’s acceptable.

  • agenda:

    Choose agenda if you need a persistent, MongoDB-backed job queue with features like job retries, concurrency control, and failure handling. It’s ideal for production applications requiring reliability, auditability, and the ability to resume scheduled jobs after server restarts. Avoid it if you don’t already use MongoDB or need lightweight, in-memory scheduling.

  • later:

    Choose later if you need advanced, human-readable recurrence rules (e.g., 'every 2nd Tuesday of the month') and plan to generate schedules programmatically. However, note that later is primarily a schedule parser and does not execute jobs by itself — you must integrate it with your own timer logic. It’s best used as a utility within custom schedulers rather than a standalone solution.

README for cron

cron for Node.js logo
cron is a robust tool for running jobs (functions or commands) on schedules defined using the cron syntax.
Perfect for tasks like data backups, notifications, and many more!

Cron for Node.js

Version Monthly Downloads Build Status CodeQL Status Coverage Renovate OpenSSF Scorecard Discord

🌟 Features

  • execute a function whenever your scheduled job triggers
  • execute a job external to the javascript process (like a system command) using child_process
  • use a Date or Luxon DateTime object instead of cron syntax as the trigger for your callback
  • use an additional slot for seconds (leaving it off will default to 0 and match the Unix behavior)

🚀 Installation

npm install cron

Table of Contents

  1. Features
  2. Installation
  3. Migrating
  4. Basic Usage
  5. Cron Patterns
  6. API
  7. Gotchas
  8. Community
  9. Contributing
  10. Acknowledgements
  11. License

⬆ Migrating

v4 dropped Node v16 and renamed the job.running property:

Migrating from v3 to v4

Dropped Node version

Node v16 is no longer supported. Upgrade your Node installation to Node v18 or above

Property renamed and now read-only

You can no longer set the running property (now isActive). It is read-only. To start or stop a cron job, use job.start() and job.stop().

v3 introduced TypeScript and tighter Unix cron pattern alignment:

Migrating from v2 to v3

Month & day-of-week indexing changes

  • Month Indexing: Changed from 0-11 to 1-12. So you need to increment all numeric months by 1.

  • Day-of-Week Indexing: Support added for 7 as Sunday.

Adjustments in CronJob

  • The constructor no longer accepts an object as its first and only params. Use CronJob.from(argsObject) instead.
  • Callbacks are now called in the order they were registered.
  • nextDates(count?: number) now always returns an array (empty if no argument is provided). Use nextDate() instead for a single date.

Removed methods

  • removed job() method in favor of new CronJob(...args) / CronJob.from(argsObject)

  • removed time() method in favor of new CronTime()

🛠 Basic Usage

import { CronJob } from 'cron';

const job = new CronJob(
	'* * * * * *', // cronTime
	function () {
		console.log('You will see this message every second');
	}, // onTick
	null, // onComplete
	true, // start
	'America/Los_Angeles' // timeZone
);
// job.start() is optional here because of the fourth parameter set to true.
// equivalent job using the "from" static method, providing parameters as an object
const job = CronJob.from({
	cronTime: '* * * * * *',
	onTick: function () {
		console.log('You will see this message every second');
	},
	start: true,
	timeZone: 'America/Los_Angeles'
});

Note: In the first example above, the fourth parameter to CronJob() starts the job automatically. If not provided or set to falsy, you must explicitly start the job using job.start().

For more advanced examples, check the examples directory.

⏰ Cron Patterns

Cron patterns are the backbone of this library. Familiarize yourself with the syntax:

- `*` Asterisks: Any value
- `1-3,5` Ranges: Ranges and individual values
- `*/2` Steps: Every two units

Detailed patterns and explanations are available at crontab.org. The examples in the link have five fields, and 1 minute as the finest granularity, but our cron scheduling supports an enhanced format with six fields, allowing for second-level precision. Tools like crontab.guru can help in constructing patterns but remember to account for the seconds field.

Supported Ranges

Here's a quick reference to the UNIX Cron format this library uses, plus an added second field:

field          allowed values
-----          --------------
second         0-59
minute         0-59
hour           0-23
day of month   1-31
month          1-12 (or names, see below)
day of week    0-7 (0 or 7 is Sunday, or use names)

Names can also be used for the 'month' and 'day of week' fields. Use the first three letters of the particular day or month (case does not matter). Ranges and lists of names are allowed.
Examples: "mon,wed,fri", "jan-mar".

📖 API

Standalone Functions

  • sendAt: Indicates when a CronTime will execute (returns a Luxon DateTime object).

    import * as cron from 'cron';
    
    const dt = cron.sendAt('0 0 * * *');
    console.log(`The job would run at: ${dt.toISO()}`);
    
  • timeout: Indicates the number of milliseconds in the future at which a CronTime will execute (returns a number).

    import * as cron from 'cron';
    
    const timeout = cron.timeout('0 0 * * *');
    console.log(`The job would run in ${timeout}ms`);
    
  • validateCronExpression: Validates if a given cron expression is valid (returns an object with valid and error properties).

    import * as cron from 'cron';
    
    const validation = cron.validateCronExpression('0 0 * * *');
    console.log(`Is the cron expression valid? ${validation.valid}`);
    if (!validation.valid) {
    	console.error(`Validation error: ${validation.error}`);
    }
    

CronJob Class

Constructor

constructor(cronTime, onTick, onComplete, start, timeZone, context, runOnInit, utcOffset, unrefTimeout, waitForCompletion, errorHandler, name, threshold):

  • cronTime: [REQUIRED] - The time to fire off your job. Can be cron syntax, a JS Date object or a Luxon DateTime object.

  • onTick: [REQUIRED] - Function to execute at the specified time. If an onComplete callback was provided, onTick will receive it as an argument.

  • onComplete: [OPTIONAL] - Invoked when the job is halted with job.stop(). It might also be triggered by onTick post its run.

  • start: [OPTIONAL] - Determines if the job should commence before constructor exit. Default is false.

  • timeZone: [OPTIONAL] - Sets the execution time zone. Default is local time. Check valid formats in the Luxon documentation.

  • context: [OPTIONAL] - Execution context for the onTick method.

  • runOnInit: [OPTIONAL] - Instantly triggers the onTick function post initialization. Default is false.

  • utcOffset: [OPTIONAL] - Specifies time zone offset in minutes. Cannot co-exist with timeZone.

  • unrefTimeout: [OPTIONAL] - Useful for controlling event loop behavior. More details here.

  • waitForCompletion: [OPTIONAL] - If true, no additional instances of the onTick callback function will run until the current onTick callback has completed. Any new scheduled executions that occur while the current callback is running will be skipped entirely. Default is false.

  • errorHandler: [OPTIONAL] - Function to handle any exceptions that occur in the onTick method.

  • name: [OPTIONAL] - Name of the job. Useful for identifying jobs in logs.

  • threshold: [OPTIONAL] - Threshold in ms to control whether to execute or skip missed execution deadlines caused by slow or busy hardware. Execution delays within threshold will be executed immediately, and otherwise will be skipped. In both cases a warning will be printed to the console with the job name and cron expression. See issue #962 for more information. Default is 250.

Methods

  • from (static): Create a new CronJob object providing arguments as an object. See argument names and descriptions above.

  • start: Initiates the job.

  • stop: Halts the job.

  • setTime: Modifies the time for the CronJob. Parameter must be a CronTime.

  • lastDate: Provides the last execution date.

  • nextDate: Indicates the subsequent date that will activate an onTick.

  • nextDates(count): Supplies an array of upcoming dates that will initiate an onTick.

  • fireOnTick: Allows modification of the onTick calling behavior.

  • addCallback: Permits addition of onTick callbacks.

Properties

  • isActive: [READ-ONLY] Indicates if a job is active (checking to see if the callback needs to be called).

  • isCallbackRunning: [READ-ONLY] Indicates if a callback is currently executing.

    const job = new CronJob('* * * * * *', async () => {
    	console.log(job.isCallbackRunning); // true during callback execution
    	await someAsyncTask();
    	console.log(job.isCallbackRunning); // still true until callback completes
    });
    
    console.log(job.isCallbackRunning); // false
    job.start();
    console.log(job.isActive); // true
    console.log(job.isCallbackRunning); // false
    

CronTime Class

Constructor

constructor(time, zone, utcOffset):

  • time: [REQUIRED] - The time to initiate your job. Accepts cron syntax or a JS Date object.

  • zone: [OPTIONAL] - Equivalent to timeZone from CronJob parameters.

  • utcOffset: [OPTIONAL] - Analogous to utcOffset from CronJob parameters.

💢 Gotchas

  • Both JS Date and Luxon DateTime objects don't guarantee millisecond precision due to computation delays. This module excludes millisecond precision for standard cron syntax but allows execution date specification through JS Date or Luxon DateTime objects. However, specifying a precise future execution time, such as adding a millisecond to the current time, may not always work due to these computation delays. It's observed that delays less than 4-5 ms might lead to inconsistencies. While we could limit all date granularity to seconds, we've chosen to allow greater precision but advise users of potential issues.

  • Using arrow functions for onTick binds them to the parent's this context. As a result, they won't have access to the cronjob's this context. You can read a little more in issue #47 (comment).

🤝 Community

Join the Discord server! Here you can discuss issues and get help in a more casual forum than GitHub.

🌍 Contributing

This project is looking for help! If you're interested in helping with the project, please take a look at our contributing documentation.

🐛 Submitting Bugs/Issues

Please have a look at our contributing documentation, it contains all the information you need to know before submitting an issue.

🙏 Acknowledgements

This is a community effort project. In the truest sense, this project started as an open source project from cron.js and grew into something else. Other people have contributed code, time, and oversight to the project. At this point there are too many to name here so we'll just say thanks.

Special thanks to Hiroki Horiuchi, Lundarl Gholoi and koooge for their work on the DefinitelyTyped typings before they were imported in v2.4.0.

⚖ License

MIT