Launched this week
Qcanary — BullMQ Monitoring Dashboard
Watch your BullMQ queues, not your Redis credentials
7 followers
Watch your BullMQ queues, not your Redis credentials
7 followers
Qcanary is a monitoring dashboard for BullMQ queues. Instead of asking for your Redis connection string, a lightweight agent runs inside your own worker process and listens to BullMQ's built-in events locally, streaming only job metadata (status, duration, errors). Your Redis credentials never leave your infrastructure. Get real-time visibility into failed and stalled jobs, instant alerts via Slack, email, or webhook, and incident history. Free tier available, no card required.
Hey Product Hunt! 👋
I'm Harsh, builder of Qcanary.
The problem we kept running into: every BullMQ monitoring tool we found wanted our Redis connection string — which means handing a third party full read/write access to production data just to see if a job failed or stalled.
Qcanary takes a different approach. A small agent (@qcanary/agent) runs inside your own worker process and listens to BullMQ's built-in events locally. It only streams job metadata over HTTPS — status, duration, error messages — never payloads, never database access, never your Redis credentials.
What you get: real-time dashboards, alerts via Slack/email/webhook when jobs fail or stall, and incident history — without the security trade-off.
Free tier is live now, no credit card required. Would genuinely love your feedback — especially if you've been burned by a monitoring tool asking for more access than it needed, or if you see a hole in how we're approaching this.
Happy to answer anything about the setup, the security model, or what's coming next. 🙏
love that the agent runs in-process, that's honestly the part that sold me on trying it. one thing i'd kill for though is some kind of job replay button for failed jobs, like being able to retry a specific one straight from the dashboard without having to dig through the redis cli or write a script. would make incident cleanup way less painful
@hseyinakca19017 Really appreciate you taking the time to try it and comment, means a lot on launch day.
Glad the in-process approach is what landed for you, that's exactly the trade-off we were trying to get right. And +1 on the replay/retry button, that's exactly the "see the problem → fix it" gap we want to close. Adding it to the roadmap.
If you get a chance to connect it to a real queue, would genuinely love to hear what else stands out, good or annoying. That kind of feedback shapes what we build next more than almost anything else right now.
love that the agent runs in your own worker instead of pulling your redis string somewhere else. that local event streaming approach is honestly a really thoughtful security-first move that most monitoring tools just skip.
@abdulsamet2lqg Thank you, genuinely, that means a lot coming from someone who clearly gets why that design choice matters.
It was actually the whole reason Qcanary exists, every tool we looked at treated "give us your Redis credentials" as an acceptable cost of getting visibility, and that never sat right with us. A monitoring tool's job is to watch, not to have full read/write access to production data.
If you end up trying it on a real queue, would love to hear what you think once it's actually running, always curious whether the experience matches the pitch.