cron vs node-schedule vs agenda vs later
Node.js Task Scheduling Libraries Comparison
1 Year
cronnode-scheduleagendalaterSimilar Packages:
What's Node.js Task Scheduling Libraries?

Task scheduling libraries in Node.js provide developers with the ability to execute code at specific intervals or times, facilitating automation and background processing in applications. These libraries help manage recurring tasks, delayed executions, and one-time jobs, enhancing the efficiency and performance of applications by offloading tasks that do not need to run in real-time. Each library offers unique features, syntax, and capabilities, making them suitable for different use cases in web development.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
cron2,914,2408,614131 kB195 days agoMIT
node-schedule2,084,1619,16335 kB1662 years agoMIT
agenda124,9099,478353 kB350-MIT
later25,6912,419-999 years agoMIT
Feature Comparison: cron vs node-schedule vs agenda vs later

Scheduling Syntax

  • cron:

    Cron employs a simple and familiar cron syntax (e.g., '0 * * * *') for scheduling tasks, which is widely recognized in the Unix/Linux community. This makes it easy for developers to quickly set up and understand job schedules.

  • node-schedule:

    Node-Schedule allows scheduling using both cron syntax and JavaScript Date objects, providing flexibility in how tasks are defined. This dual approach caters to developers who prefer either method for scheduling.

  • agenda:

    Agenda uses a fluent API for defining jobs, allowing for easy configuration and management of job schedules. It supports a variety of scheduling options, including recurring jobs and delayed executions, making it intuitive for developers familiar with MongoDB.

  • later:

    Later provides a more flexible syntax that allows for complex scheduling scenarios, including intervals and specific dates. It supports human-readable expressions, making it easier to define intricate schedules without deep technical knowledge.

Persistence and Reliability

  • cron:

    Cron does not provide built-in job persistence; if the application crashes, scheduled jobs may be lost. It's best suited for lightweight tasks that do not require persistence or reliability.

  • node-schedule:

    Node-Schedule also lacks built-in persistence, relying on in-memory scheduling. It is suitable for short-lived tasks but may require additional handling for reliability in long-running applications.

  • agenda:

    Agenda excels in job persistence, storing job details in MongoDB, which ensures that jobs are not lost even if the application crashes. It also supports job retries and concurrency, enhancing reliability in task execution.

  • later:

    Later does not inherently support job persistence, focusing instead on in-memory scheduling. This makes it less reliable for long-running applications unless combined with additional persistence mechanisms.

Complexity and Learning Curve

  • cron:

    Cron is very easy to learn, especially for those familiar with Unix/Linux systems. Its straightforward syntax allows developers to quickly implement basic scheduling without much overhead.

  • node-schedule:

    Node-Schedule is relatively easy to learn, especially for those familiar with JavaScript. Its dual scheduling methods provide flexibility, but understanding the nuances of each method may take some time.

  • agenda:

    Agenda has a moderate learning curve due to its integration with MongoDB and the need to understand job management concepts. However, its API is well-documented and intuitive for developers familiar with database interactions.

  • later:

    Later has a slightly steeper learning curve due to its flexible syntax and advanced scheduling capabilities. Developers may need to invest time in understanding its features to fully leverage its potential.

Use Cases

  • cron:

    Cron is best suited for simple, recurring tasks like cleaning up temporary files, sending periodic reports, or executing maintenance scripts that do not require persistence.

  • node-schedule:

    Node-Schedule is versatile for various use cases, including scheduled API calls, automated data processing, and any task that can benefit from either cron-like scheduling or JavaScript Date-based scheduling.

  • agenda:

    Agenda is ideal for applications that require complex job management, such as background processing, email notifications, and data synchronization tasks that need to be persistent and reliable.

  • later:

    Later is perfect for applications that need advanced scheduling capabilities, such as event-driven architectures or applications that require precise timing for tasks based on user interactions.

Community and Support

  • cron:

    Cron is widely used and has a large community, providing ample resources and examples for developers. Its simplicity contributes to its popularity and ease of adoption.

  • node-schedule:

    Node-Schedule has a decent community and is well-documented, making it accessible for developers. Its versatility ensures that it is used in various projects, leading to a growing number of shared resources.

  • agenda:

    Agenda has a strong community and good documentation, making it easier for developers to find support and examples. Its integration with MongoDB also means that many developers are familiar with its usage.

  • later:

    Later has a smaller community compared to others, but it is well-documented. Developers may find fewer resources, but the library's flexibility compensates for this.

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

    Select Cron if you prefer a simple syntax for scheduling tasks using cron-like expressions. It's lightweight and straightforward, making it suitable for basic scheduling needs without additional overhead.

  • node-schedule:

    Use Node-Schedule if you want a versatile library that allows you to schedule jobs using cron syntax or JavaScript Date objects. It's suitable for applications that need a straightforward solution for scheduling tasks without the need for a database.

  • agenda:

    Choose Agenda if you need a robust job scheduling library that integrates seamlessly with MongoDB and supports job persistence, retries, and concurrency. It's ideal for applications that require complex job management and monitoring.

  • later:

    Opt for Later if you need a flexible scheduling library that supports complex scheduling scenarios, including intervals, specific dates, and recurring patterns. It's great for applications that require advanced scheduling capabilities without a heavy dependency.

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):

  • 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.

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