Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Matheus Morett, CTO and software engineer at Monest, says the company handles more than 100 million BullMQ jobs a day and built Bullpane after its existing dashboards stopped meeting the team’s operational needs. His account is a first-person case study, not an independently audited workload or a controlled product comparison.
Why Monest needed a different BullMQ dashboard
In Morett’s description, Monest’s workflow begins when a webhook arrives: the message is queued, an agent drafts a reply, and Monest sends it. At that scale, the dashboard is part of operating the queue, not just a way to look at jobs.
The team initially used bull-board behind a VPN with shared credentials. Morett says that arrangement did not answer basic accountability questions: who deleted a job, who paused a queue, and which team members should be allowed to retry or remove jobs. Developers needed to inspect queues, while retry and removal powers were to remain with tech leads.
Recommended Free Tools
Morett says the team next used Taskforce. He found its alerts useful, but describes its day-to-day interface as slow and clunky. Those are his impressions, not results from a comparative usability or performance test. The BullMQ repository describes Taskforce as BullMQ’s official frontend, with queue overviews, job inspection, search, retry, delayed-job promotion, metrics, and statistics: BullMQ repository README.
#1 Best Overall
What Bullpane was designed to change
Morett says he built Bullpane around getting attention to the queues that need it and reducing the friction of common investigations. He cites a keyboard shortcut for moving among queues, search across job payloads, and inspection of BullMQ Pro groups. His example of a search question is, “Which job had order 81723?”
The article also describes operational controls and organization features:
- Permissions: Pro roles are enforced on API calls, so access restrictions apply to operations rather than merely hiding interface controls.
- Audit history: Append-only logs record actions, with CSV export.
- Authentication: OIDC or SAML single sign-on is listed.
- Alerts and organization: Configurable alerts and folders are described.
These are Bullpane capabilities as reported by Morett’s article, not independent verification of the current product. The article’s account distinguishes its focus—permissions, auditability, queue prioritization, and payload search—from the feature set the BullMQ repository attributes to Taskforce. It does not establish that one dashboard is categorically better, or compare their performance under the same conditions.
How Bullpane aims to limit pressure on Redis
A dashboard that reads a busy queue can itself add load. Morett summarizes the design concern this way: “A dashboard that slows down the workload it watches is worse than no dashboard.” He describes several choices intended to keep reads bounded and writes safe:
Rank #3
- Queue discovery: bounded, cached Redis SCAN rather than the potentially disruptive KEYS command.
- Counts and pages: Lua scripts invoked with EVALSHA.
- Large payloads: truncation happens inside Redis, before the full payload is returned to the dashboard.
- Writes: BullMQ’s official client is used for write operations.
- Initial production use: a read-only mode lets operators begin by observing queues without enabling dashboard actions.
The design choices explain the intended safeguards; they do not, by themselves, establish how Bullpane behaves on every Redis deployment or workload. Teams should assess the current implementation and test it against their own queue configuration and operational constraints.
What the reported performance numbers do—and do not—show
Morett’s article reports a 7 ms time for a page of 200 jobs with 1 MB payloads, and 8 ms for a search across 1,000 such jobs. These are claims in the article; the test setup and conditions are not independently verified here. They are not general latency expectations, guarantees, or a like-for-like comparison with bull-board or Taskforce. The article points to a STRESS-TEST.md file and describes a hostile-load test, but the test contents and setup are not established in the available account.
Licensing and price reported in the article
Morett’s article says Bullpane’s core is free and MIT-licensed, and lists Pro at USD 39 per month per installation for unlimited users. These terms are article-reported and may have changed; confirm current licensing, features, and pricing with Bullpane before choosing it. The article does not establish a current partner relationship or independently verify these commercial details.
What this case study is useful for
The account is most useful as a checklist for teams whose BullMQ dashboards have become part of production operations. A queue view may be insufficient when teams also need to know who changed a job, separate inspection from destructive actions, find jobs by payload data, and keep monitoring reads from becoming a source of additional load. Morett’s Monest workload and Bullpane measurements provide context for why he pursued those requirements, but remain his reported figures rather than independent benchmarks.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
