This "ready" event is emitted when the "blocking" (dedicated) Redis connection is ready. This event is actually generated by IORedis, signalling that the connection has been correctly stablished and is ready to accept Redis commands:

So in your case I am not sure why this happens but there are situations when we need to force-disconnect the blocking connection and reconnect again, that would generate a new "ready" event:

Having said that, I suspect you are using this event for something else, as this event as is is not particularly useful. If you describe your use case we may be able to find a better way to do it than using this event.

Much appreciated for the details on the origination. We are looking to identify the number of worker threads that are globally connected and working by Worker and Queue. e.g. if there are 10 instances of Worker A on Pod A and 5 instances of Worker A on pod B we would observe two values of 10 and 5. If Pod B had 2 workers that had issues with their redis connections (memory overflow something impacting limiting cpu timeouts heartbeats), The values would start reporting as 10 and 3.

We are looking to alert when worker instance counts go outside of a boundary.

What about the "getWorkers" and "getWorkersCount" APIs, are they not useful for your case?
https://api.docs.bullmq.io/classes/v5.Queue.html#getWorkers

In BullMQ you can also set a specific name for your workers if you want and you will get this name back when calling "getWorkers": https://api.docs.bullmq.io/interfaces/v5.WorkerOptions.html#name

Thank you these are definitely the aggregations we are looking for.

Will calling these operations on a timer, like every 5 seconds be a problem?

Probably not a problem, depends if you have many workers or not, you can make some benchmarks to see how long that call takes. I would try to increase the interval as much as possible, every 30 seconds even better.

Thank you for the time and feedback!