BullMQ dashboard
built for production workflows
See failed jobs, queue backlogs, payloads, stack traces, and worker logs without adding agents or changing worker code.
at processImage (worker.ts:84)
at Worker.process (worker.ts:41)
"fileId": "img_9f3a",
"format": "webp"
}
How it works
Live data in under 60 seconds.
No agents. No code changes. No instrumentation.
Paste your Redis URL
TLS and ACL users supported out of the box. Works with every major managed provider. Add a dedicated read-only ACL user for monitoring, or write access if you want admin actions.
rediss://unqueue-read:[email protected]:6380/0
Queues appear automatically
unqueue scans your Redis keyspace using BullMQ's key schema. No queue registration, no manifest file. New queues appear the moment workers create them.
Discovered: email-queue, image-processing, notifications
Watch jobs in real time
Live updates stream via BullMQ's QueueEvents — the same event system your workers already use. Click any job to see its input, output, logs, and failure details.
If you run BullMQ in production, you've hit these.
A user emails you. That's how you find out a job failed.
Know the instant it happens — error, stack trace, and the exact input that caused it. Before anyone else notices.
Debugging a stuck queue means redis-cli LLEN, ZRANGE, HGETALL. Copy-pasting job IDs. Every time.
Click any job. Input, output, logs, and failure reason — all in one place. No terminal. No copy-pasting.
Slow throughput. Is it the worker? Redis? Just high load? You genuinely don't know.
Processing rate and failure rate over a rolling window. See exactly what changed and when.
Built around how engineers actually debug queues.
Not a generic APM bolted onto BullMQ. A tool that reads BullMQ's data model directly and shows you what actually matters.
Job inspection
Know exactly why a job failed.
A failure count tells you nothing. unqueue surfaces the full picture: error message, stack trace, the input data that triggered it, and every structured log your worker emitted — all attached to that specific job.
- Full stack trace on every failure
- Input data and return value stored with the job
- Structured worker logs tied to the job that produced them
Error: Sharp conversion failed
at processImage (worker.ts:84)
at Worker.process (worker.ts:41)
Input data
{ fileId: "img_9f3a", format: "webp" }
Worker logs
info Downloading file img_9f3a
info Converting to webp (1920x1080)
error Unsupported pixel format: cmyk
Queue discovery
All your queues, no setup required.
Most tools require you to register queues manually. unqueue reads BullMQ's key schema directly from Redis. New queues appear the moment workers create them — nothing to configure, nothing to maintain.
- Auto-discovery via BullMQ key prefix scan
- Queues appear and disappear automatically
- Works with any BullMQ key prefix
pdf-export appeared when a worker registered it
Admin actions
Fix problems without redis-cli.
When jobs pile up or fail in bulk, you need to move fast. Retry, pause, drain, or obliterate — directly from the dashboard. No hand-crafted Redis commands, no context-switching to a terminal.
- Retry failed jobs individually or in bulk
- Pause, drain, clean, and obliterate queues
- Discord alerts when queues spike or jobs consistently fail
Discord alert
🔴 email-queue failure rate exceeded 5% over 15 minutes
47 failed · 0 active · production
The questions you're probably asking.
"My job payloads contain sensitive data."
unqueue never stores your job data. Every request reads directly from your Redis instance on demand — nothing is persisted, cached, or transmitted elsewhere. If that's not enough, self-host with a single docker compose up. You control the infrastructure.
Self-host docs →"What if you shut down or start charging?"
AGPL-3.0. Every line of code is on GitHub — fork it, run it, own it. The self-hosted version is identical to the cloud version, no features gated. You're never locked in.
View source →"We already have Datadog and Grafana."
Those solve infrastructure observability. unqueue solves job observability — a different layer entirely. Datadog can tell you a worker process crashed. It can't tell you which job caused it, what the input was, or what your worker logged before it failed. Unless you've already built structured logging that correlates job IDs to failure state, you don't actually have that coverage.
Open source. No black boxes.
AGPL-3.0 · React + Hono · Docker Compose deploy · Self-hosted = same software
FAQ
Common questions.
unqueue supports BullMQ v3 and v4. It reads BullMQ's Redis key schema directly, so as long as your workers use a supported version, no changes are needed on your end.
Read-only access is enough for monitoring — browsing queues, inspecting jobs, and viewing logs. Write access is required only if you want admin actions like retrying jobs, pausing queues, or draining backlogs.
Minimal. unqueue subscribes to BullMQ's QueueEvents channel (a single pub/sub connection) and issues read commands on demand when you open a job or queue. It does not poll continuously or scan keyspaces on a schedule.
Yes. You can add as many Redis connections as you need — one per environment, region, or microservice. Each connection is managed separately and shows its own set of queues.
Yes. BullMQ Pro uses the same underlying Redis schema for standard queue and job data. Pro-specific features like groups are displayed where applicable.
unqueue will show the connection as offline and stop receiving live events. No data is lost — when the connection is restored, queue state is re-read from Redis and the dashboard updates automatically.
No artificial limits on queues. Job list views are paginated to keep things fast, but you can navigate freely across all jobs in any state.
Yes. unqueue lets you configure a custom key prefix per Redis connection, matching whatever prefix you pass to your BullMQ Queue constructor.
Stop debugging queues blind.
Self-host unqueue for free today, or join the hosted waitlist.
Hosted does not exist yet. The open-source version is available now.