At Monest we run everything after the webhook on BullMQ. Messages come in, get queued, an agent drafts a reply, we send it. Today that is more than 100 million jobs a day.
At some point somebody said the obvious thing: we need to see these jobs.
bull-board: good, until the team grew
We installed bull-board. It was nice. It worked. It did exactly what it says.
The first problem showed up on day one: it had no login. Easy fix. We put it behind the VPN and added a user and a password in front of it.
Then the team grew, and the questions changed:
- What if someone deletes a job? How do we find out who?
- Who paused this queue, and why?
- Can devs look, and only tech leads retry or remove?
None of that was possible. One shared password means everyone is everyone.
Taskforce: alerts, and a UI that got in the way
So we moved to Taskforce, the dashboard from the BullMQ team. The alerts were genuinely useful. Day to day, though, the UI felt slow and clunky to the people who lived in it.
So I built the one I wanted
That is Bullpane.
What it does:
- The queues that need you are at the top. Open it and you see which queues are breaking a rule (
25% failed · 15m > 3%,780 waiting > 200) before anything else. - ⌘K to jump to any queue on any connection.
- Search inside job data. "Which job had order 81723?" In bull-board, search matches queue names. Here you search the payload, bounded and resumable, so it never blocks Redis.
- BullMQ Pro groups shown as groups: waiting, limited, maxed, paused, with concurrency and rate limit per group.
And for the team problems that started all this (Pro):
- Roles. Devs get viewer, tech leads get operator, and the server enforces it on every API call, not just by hiding buttons.
- Audit log. Who paused the queue, who removed the job, who hit retry-all, from which IP. Append-only, CSV export.
- SSO over OIDC or SAML, so you stop sending invites one by one.
- Alerts per queue, per folder or per whole connection, to Slack or a webhook.
- Folders to group queues the way the team thinks about them.
The part I cared about most: not hurting Redis
A dashboard that slows down the workload it watches is worse than no dashboard. At 100M jobs a day, the dashboard is a guest in a very busy Redis. So:
- No
KEYS, ever. Discovery is a boundedSCAN, cached. - One round trip per read: counts and pages are Lua scripts over
EVALSHA. - Payloads are truncated inside Redis. A page of 200 jobs with 1 MB payloads costs 7 ms; a search over 1,000 of them, 8 ms.
- Writes go through the official
bullmqclient. I never reimplemented its Lua. - A read-only mode for the first days on production.
The numbers and the hostile-load test are in the repo: STRESS-TEST.md.
Try it
- Live demo, no login: demo.bullpane.com (read-only, a simulated busy company)
- Run it next to your stack:
git clone https://github.com/madmorett/bullpane && cd bullpane
docker compose up -dThen add your Redis URL. Start with BULLPANE_READ_ONLY=true.
The core is free and MIT, with no account and no login. Pro (roles, audit, SSO, alerts, folders) is USD 39/month per installation, unlimited users.
It is what we run at Monest today. If you try it on your queues, tell me what broke: hello@bullpane.com or an issue on GitHub.