If you’ve worked with Redis-based queues like BullMQ, you’ve probably had this moment:
Everything looks fine.
- No crashes.
- No logs screaming in red.
- CPU is calm.
And yet…
A customer reports they never got their email. Or your nightly job didn’t run. Or a report didn’t get generated.
And the worst part? You didn’t know anything was wrong.
Common Queue Pitfalls (That No One Tells You About)
1. Failed Jobs Don’t Always Scream: You can configure retries, but failed jobs often just sit in their designated “failed” state quietly. Unless you’re actively monitoring, these can pile up without notice.
2. Stuck Queues Look Idle: A job gets stuck processing due to a bad dependency or network call. That one job blocks everything behind it, but from the outside, it just looks like… nothing is happening.
3. Crashed Workers = Silent Failure: BullMQ doesn’t auto-scale or auto-recover workers. If your queue relies on one or two workers and one crashes, it could take you hours to notice.
4. Redis Memory Can Be a Bottleneck: Redis doesn’t warn you gently when it runs out of memory. It just stops accepting writes. If your queue system relies on writes, things will break.
What Can You Do?
Monitor actively. Whether it’s your own scripts or third-party tools, make sure you know:
- How many failed jobs exist per queue
- If your worker count suddenly drops
- When your Redis memory usage spikes
Set thresholds; Alert only when a threshold is crossed, to avoid noise.
Don’t just react – observe; A lot of queue failures don’t come from crashing—they come from silence. Build systems that highlight inactivity, not just errors.
We started thinking more about this after hitting all of the above pain points. At some point we needed better visibility and built internal tooling around it.
There are tools out there (we put something lightweight together ourselves at upqueue.io) but regardless of what you use – just don’t let your queues go dark.
Silence in production is not always peace.
Sometimes, it’s a red flag.
