Compare ten Node.js scheduling libraries

Choose among in-process cron libraries, worker-thread schedulers, and persistent job queues based on recovery and coordination needs.

Guance Editorial Team 5 min read Updated 2026-10-20

Best practices

Compare ten Node.js scheduling libraries

Start with the execution guarantee you need. A small recurring action may fit an in-process library such as node-cron. Durable work and coordination across workers call for a persistent queue or scheduler, such as BullMQ or a supported Agenda backend. Bree addresses a different concern: running jobs in worker threads.

Persistence alone does not prevent duplicate business effects. Define retries, idempotency, and reconciliation for work whose loss or repetition matters.

1. BullMQ

BullMQ is a Redis-backed job queue with delayed jobs, recurring scheduling, retries, concurrency limits, and priorities. It also has monitoring integrations such as Taskforce.sh.

Shared Redis state coordinates workers, but stalled-job recovery and retries can execute work more than once. Make handlers idempotent. For current versions, use the documented Job Schedulers API; it supersedes the older repeatable-job API, which was deprecated from 5.16 and removed in version 6.

2. Agenda

Agenda persists jobs and supports recurring schedules and concurrency controls. Older releases are closely associated with MongoDB. The current project also documents official PostgreSQL and Redis backends, so check the installed major version before choosing a storage integration.

A MongoDB-backed deployment can be attractive when that database is already operated by the team. Agenda also supports multiple workers; it is not limited to single-instance scheduling.

3. Bree

Bree runs jobs in worker threads and supports interval and cron-style schedules. It is useful when work should run outside the main event loop, including CPU-heavy JavaScript.

Threads still share the host's CPU and process lifecycle. Bree does not automatically give those jobs durable queue semantics; store business state externally when needed.

4. node-schedule

node-schedule is an in-process scheduler with cron expressions and object-based recurrence rules. Schedules disappear when the process exits and must be registered again on startup.

It can be used in production when an external service owns durability or when missed runs are acceptable. The distinction is the recovery requirement, not whether the environment is called development or production.

5. Cron, the `cron` package

The package named cron provides cron scheduling with seconds and time-zone support. It keeps scheduling state in the application process. Account for the installed major version's API and overlap controls.

6. CronosJS

CronosJS offers cron scheduling in Node.js and browsers, with extended expressions and time-zone handling. It is another in-process option. Its API and calendar behavior should be tested against the actual expression and zone you plan to use.

7. node-cron

node-cron provides a compact API:

cron.schedule('* * * * *', fn);

Import the package and define fn in your application. It is convenient for lightweight schedules, but the schedule and process lifecycle remain your responsibility. Current project documentation also describes optional distributed coordination; verify support in your installed version and configure the coordinator explicitly. Coordination does not turn it into a durable queue. Avoid interpreting a small API as a measured performance ranking against every other library.

8. Croner

Croner is a dependency-free cron library supporting Node.js, Deno, Bun, and browsers. It supports seconds and named time zones.

For daylight-saving transitions, test the desired behavior around missing or repeated local times. “Supports time zones” does not by itself define the business policy for every transition.

9. Bottleneck

Bottleneck primarily controls rate and concurrency, rather than providing calendar scheduling. Use it to throttle calls to a rate-limited API or to constrain simultaneous work. It can complement a scheduler that decides when to submit tasks.

10. toad-scheduler

toad-scheduler provides in-memory interval tasks and a cron integration using Croner. It includes controls for avoiding overlap within a scheduler. It does not, by itself, coordinate jobs across separate processes or preserve pending work through a crash.

Choose by the failure model

Must work survive a process restart?
├─ No: consider node-cron, Croner, cron, node-schedule, or CronosJS
└─ Yes: evaluate BullMQ or an appropriate Agenda backend
        └─ Multiple workers: verify shared-store coordination and lock behavior

CPU-heavy execution?
└─ Evaluate worker threads, Bree, or separate worker processes

Storage durability, worker capacity, retry policy, and reconciliation matter more than whether an expression has five or six fields.

FAQ

Will every application replica run the same schedule?

If each independently registers an in-memory schedule, each can trigger it. Use a designated scheduler, leader coordination, or shared persistent infrastructure when only one logical trigger is intended. BullMQ and Agenda coordinate workers, but do not guarantee exactly-once business effects.

Will missed times be replayed after downtime?

Do not assume every missed interval becomes a queued execution. BullMQ's older repeatable jobs do not accumulate every missed run while workers are absent, and Job Schedulers produce subsequent jobs as processing advances. Agenda's behavior depends on its version, stored next-run state, recurrence, and configuration. Test recovery and reconcile expected business periods explicitly.

Which libraries support seconds?

node-cron, cron, Croner, and BullMQ scheduling support second-level expressions in their documented formats. High-frequency work also needs a clear overlap and backlog policy; syntax support alone says little about whether workers can keep up.

References

The comparison describes documented behavior, not a benchmark of these libraries in this project.