BullMQ monitoring
Use Bull Board or Taskforce.sh to see queues and jobs, and add a 10-second job scheduler that pings a Logdash push monitor so you are told when workers stop processing.
The first answer to BullMQ monitoring is a dashboard, and Logdash is not one. If you want to read a failed job's payload and stack trace, start with one of these:
BullMQ UI and dashboard options
- Bull Board: free, MIT licensed, mounted as a route in Express, Fastify and other servers. A viewer with no alerts, so put it behind your own auth.
- Taskforce.sh: hosted by the BullMQ team, from $19.95 a month for one Redis connection after a 15-day trial. Alerts on failed jobs, missing workers and backlog by email, Slack or PagerDuty.
- Logdash: no queue view at all. A heartbeat, uptime checks on the API and logs from the Node.js SDK.
What a dashboard does not do is ring when everything goes quiet. A worker that lost Redis, a deploy that never started the worker process, a concurrency of 1 stuck behind a job that never resolves: the queue just stops moving. Logdash covers that one question, is anything being processed, with a heartbeat that only arrives if a worker processed it.
BullMQ queue monitoring with a heartbeat job
import { Queue, Worker, type Job } from 'bullmq';
const connection = { host: 'localhost', port: 6379 };
const PING_URL = 'https://api.logdash.io/ping/68b4c1f0e3a2d5c7b9f01234';
// Upsert, so restarts and extra replicas never create duplicates.
await new Queue('jobs', { connection }).upsertJobScheduler(
'logdash-heartbeat',
{ every: 10_000 },
{ name: 'heartbeat', opts: { removeOnComplete: true, removeOnFail: true } },
);
new Worker(
'jobs',
async (job: Job) => {
if (job.name === 'heartbeat') {
await fetch(PING_URL, { method: 'POST', signal: AbortSignal.timeout(5_000) });
return;
}
// ...your existing handlers
},
{ connection },
);Job schedulers arrived in BullMQ 5.16 and are the only way left in v6, which removed the repeat option on queue.add in July 2026. A scheduler creates the next job only when the last one starts processing, so dead workers do not leave thousands of stale heartbeats behind to replay later. Node 18 and later ship fetch. BullMQ 6 no longer bundles ioredis, so install it next to bullmq.
Why 10 seconds
Push monitors are a Pro feature. On Pro, Logdash looks for a ping every 15 seconds and marks the monitor down on the first window without one. There is no grace setting, so the heartbeat runs every 10. Putting it on your main queue turns it into a stall alarm: if the worker is busy for 15 seconds, you hear about it. If long jobs are normal, raise concurrency or move the heartbeat to its own queue and worker. An hourly repeatable job cannot feed this monitor directly. For those, set a Redis key with an expiry when the job completes and point an HTTP monitor at a route that returns 503 once the key is gone.
- Create a push monitor Add a service on Pro, set the monitor to push and copy the id from the ping URL into PING_URL.
- Deploy the worker The scheduler upserts on start and the monitor goes up on the first check after the first heartbeat.
- Stop the worker Connect a Telegram channel, then kill the worker process. Within 30 seconds a Telegram alert says the monitor is down, and an up message follows when it restarts.
Logdash vs Taskforce.sh
| Feature | Logdash | Taskforce.sh |
|---|---|---|
| Queue and job inspection | None | Every queue, job, payload and stack trace |
| Retry and clean jobs by hand | Not built | From the dashboard |
| Alert on failed jobs and backlog | Only as a late heartbeat | Failed jobs, missing workers, backlog, memory |
| Alert when nothing is processed | Heartbeat, 15 to 30 seconds | Missing worker alert |
| Uptime checks on the API | HTTP monitors with response time | Not covered |
| Price | Pro, $15 a month | From $19.95 a month |
When Taskforce.sh is the better pick
- You need to see why a job failed: payload, attempts, stack trace. Logdash sees one ping.
- You want alerts on failed jobs and queue size, not only on a stopped worker.
- You only want a UI and already have auth in front of your app. Then Bull Board is free and enough.
- You run several Redis instances and want every queue on them in one view.