Skip to main content

Overview

BullMQ provides a comprehensive event system to monitor job lifecycle and queue operations. Events can be listened to at different levels: Queue, Worker, and QueueEvents.

Event Types

Queue Events (Local)

These events are emitted by the Queue instance that performs the operation:

Worker Events (Local)

These events are emitted by the Worker instance processing jobs:

Global Events (QueueEvents)

QueueEvents listens to events from all workers and queues for a given queue name:
QueueEvents requires a dedicated Redis connection and uses blocking operations to listen for events in real-time.

Queue Event Reference

waiting

Emitted when a job is added to the queue:

progress

Emitted when a job’s progress is updated:

removed

Emitted when a job is removed:

cleaned

Emitted when jobs are cleaned:

paused / resumed

Emitted when the queue is paused or resumed:

error

Emitted on errors:

Worker Event Reference

active

Emitted when a job starts processing:

completed

Emitted when a job completes successfully:

failed

Emitted when a job fails:
The job parameter can be undefined if the job reached the stalled limit and was removed by the removeOnFail option.

progress

Emitted when a job reports progress:

drained

Emitted when the queue has no jobs waiting:

stalled

Emitted when a job is detected as stalled:

paused / resumed

Emitted when the worker is paused or resumed:

ready

Emitted when the worker’s blocking connection is ready:

closing / closed

Emitted during worker shutdown:

error

Always add an error listener to prevent unhandled exceptions!

QueueEvents Reference

added

Emitted when a job is created:

active

Emitted when a job becomes active:

completed

Emitted when a job completes:

failed

Emitted when a job fails:

progress

Emitted on progress updates:

delayed

Emitted when a job is delayed:

removed

Emitted when a job is removed:

waiting

Emitted when a job enters waiting state:

waiting-children

Emitted when a job is waiting for children:

stalled

Emitted when a job stalls:

retries-exhausted

Emitted when a job exhausts all retry attempts:

deduplicated

Emitted when a job is rejected due to deduplication:

duplicated

Emitted when a job with the same ID already exists:

drained

Emitted when the waiting list is emptied:

paused / resumed

cleaned

Emitted when jobs are cleaned:

Event Comparison

Scope: Local to the Queue instanceUse case: Monitor operations performed by this specific queueConnection: Uses the queue’s main connectionEvents: waiting, progress, removed, cleaned, paused, resumed

Job-Specific Events

Listen to events for a specific job:

Event Resumption

Resume listening from a specific event ID:

TypeScript Support

Type-safe event listeners:

Event Best Practices

Always Handle Errors

Add error listeners to Queue, Worker, and QueueEvents to prevent crashes.

Use QueueEvents for Monitoring

Use QueueEvents for centralized monitoring across all workers.

Clean Up Listeners

Remove event listeners when no longer needed to prevent memory leaks.

Don't Block Event Handlers

Keep event handlers fast. For heavy operations, queue another job.

Example: Complete Event Monitoring

Next Steps

Workers

Learn how to process jobs with workers

Jobs

Understand job lifecycle and manipulation

Queues

Explore queue operations