Everything you wished bull-board showed you
Real screenshots, running against a BullMQ Pro queue and a busy demo. No mockups. If it is on this page, it is on the screen.
Any queue in one keystroke
Waiting and failed counts in the result, so you know which one is on fire before you open it.
Retry, remove, promote. One job or two hundred.
The failure reason sits in the row. No click, no modal.
Jobs you can actually read
Timeline, data as a tree, options, return value, stack trace, logs, and who touched it.
BullMQ Pro groups, with every per-group setting
Waiting, limited, maxed, paused. Concurrency cap, rate limit, and exactly when a limited group resumes.
Metrics from BullMQ's own counters
Throughput, rate and success per minute, from the counters your workers already write.
How the queue is configured, without opening the code
Library and version, workers connected, concurrency, rate limit. When Redis cannot tell, it says so.
Server health, one read every three seconds
Redis: memory, CPU, commands per second, latency, clients, keys. Postgres: connections, transactions per second, table sizes and BullMQ’s untrimmed event table. Ten tabs cost your server as much as one.
Every scheduler, across every queue
What fires next, in the next hour or the next week, and what is overdue.
Any queue in one keystroke
Waiting and failed counts in the result, so you know which one is on fire before you open it.
Retry, remove, promote. One job or two hundred.
The failure reason sits in the row. No click, no modal.
Jobs you can actually read
Timeline, data as a tree, options, return value, stack trace, logs, and who touched it.
BullMQ Pro groups, with every per-group setting
Waiting, limited, maxed, paused. Concurrency cap, rate limit, and exactly when a limited group resumes.
Metrics from BullMQ's own counters
Throughput, rate and success per minute, from the counters your workers already write.
How the queue is configured, without opening the code
Library and version, workers connected, concurrency, rate limit. When Redis cannot tell, it says so.
Server health, one read every three seconds
Redis: memory, CPU, commands per second, latency, clients, keys. Postgres: connections, transactions per second, table sizes and BullMQ’s untrimmed event table. Ten tabs cost your server as much as one.
Every scheduler, across every queue
What fires next, in the next hour or the next week, and what is overdue.
- Every state, every queue, every connection. Waiting, active, delayed, prioritized, completed, failed, paused, waiting-children.
- Search inside job data, bounded and resumable, so a big state never blocks Redis.
- Bulk actions on a selection: retry, promote, remove. Drain and obliterate behind the admin role.
- Flow tree per job: the real parent and child instances, bounded so 50k children return a slice, not 50k nodes.
- Delayed jobs say when they run, correct after a backoff retry too.
- Read-only mode for the first days on a production Redis you do not trust yet.
