Skip to main content
From BullMQ version 5.16.0 onwards, repeatable job APIs are deprecated in favor of Job Schedulers, which provide a more cohesive and robust API for handling repeatable jobs.

Overview

Repeatable jobs are a special type of meta job that keep repeating according to a predefined schedule. Adding a job with the repeat option:
  1. Creates a Repeatable Job configuration
  2. Schedules a regular delayed job for the job’s first run
The first run is scheduled “on the hour” - for example, a job repeating every 15 minutes created at 4:07 will first run at 4:15, then 4:30, and so on.
Repeatable Job configurations are not actual jobs, so they won’t show up in methods like getJobs(). Use getRepeatableJobs() to manage them instead.

Scheduling Methods

There are two ways to specify a repeatable job’s pattern:

Cron Pattern

Uses cron-parser’s “unix cron w/ optional seconds” format:

Fixed Interval

Specify milliseconds between repetitions:

Important Considerations

No Duplicates

BullMQ won’t add the same repeatable job if the repeat options are identical.

No Accumulation

If no workers are running, repeatable jobs won’t accumulate. They’ll resume when workers come back online.

Manual Removal

Use removeRepeatable() or removeRepeatableByKey() to remove repeatable job configurations.

Unique IDs

Repeatable jobs require unique IDs to avoid being considered duplicates.

Removing Repeatable Jobs

Get All Repeatable Jobs

Job IDs with Repeatable Jobs

The jobId option works differently for repeatable jobs. It’s used to generate unique IDs rather than being the unique ID itself:

Slow Repeatable Jobs

If job processing time exceeds the repeat frequency:
With 1 worker:
  • Next job is added to the delayed set when the current job starts processing
  • The worker takes 5 seconds to complete
  • Next job waits in the queue until the worker is free
  • Effective frequency: every 5 seconds (not 1 second)
With 5 workers:
  • Workers can maintain the desired 1 second frequency
  • Each worker processes jobs in parallel

Custom Repeat Strategy

You can define a custom strategy for scheduling repeatable jobs. Here’s an example using RRULE:
The repeat strategy setting must be provided in both Queue and Worker classes:
  • Queue: Calculates the first iteration when adding the job
  • Worker: Calculates subsequent iterations during processing
The repeat strategy function receives an optional jobName third parameter.

Custom Repeatable Key

By default, repeatable keys are generated based on repeat options and job name. You can provide a custom key to differentiate repeatable jobs with the same repeat options:

Updating Repeatable Job Options

Using custom keys allows updating existing repeatable jobs:
This updates the existing repeatable job’s interval without creating a new one. Any delayed job for the old interval is replaced with the new settings.

Read More

Repeat Strategy API

View the Repeat Strategy type definition

Remove Repeatable Job

removeRepeatable API Reference

Remove by Key

removeRepeatableByKey API Reference

Job Schedulers

Modern approach to scheduled jobs (recommended)