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: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
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
- Queue Events
- Worker Events
- QueueEvents
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, resumedJob-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
