---
title: "BullMQ monitoring: dashboards and heartbeats | Logdash"
description: "Bull Board and Taskforce.sh show your queues. A 10-second job scheduler and a Logdash push monitor tell you when nothing is being processed."
url: https://logdash.io/cron-monitoring/bullmq
---

# 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

 worker.ts 

```typescript
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.

1. **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.
2. **Deploy the worker** The scheduler upserts on start and the monitor goes up on the first check after the first heartbeat.
3. **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.

### What is the best BullMQ UI? 

Bull Board if you want free and self-hosted: MIT licensed, mounted as a route in Express or Fastify, no alerts. Taskforce.sh if you want it hosted with teams and alerts. Bull Board shows a dead worker only when you open it; Taskforce.sh alerts on it.

### Which BullMQ dashboard should I use? 

For one app with auth already in place, Bull Board. For production with several people and alerting, Taskforce.sh, which connects through an outgoing connector so Redis stays private.

### Is Logdash a BullMQ monitoring tool? 

For one question: is a worker still processing jobs. It does not read your queues. Pair it with a dashboard, and use it for the heartbeat, uptime checks on the API, and logs from the Node.js SDK.

### How does BullMQ queue monitoring catch a stuck queue? 

Put the heartbeat on the same queue as the real work. If jobs stop moving for 15 seconds, the heartbeat stops too and the monitor alerts. Use a separate queue only if long jobs are normal.

## Keep reading

[All cron monitoring guides](https://logdash.io/cron-monitoring): One guide per scheduler, each with the code that proves a job ran and the alert for when it did not.

[Kubernetes CronJob monitoring](https://logdash.io/cron-monitoring/kubernetes-cronjob): Kubernetes records when each CronJob last succeeded in status.lastSuccessfulTime and never alerts on it, so either alert on that timestamp in Prometheus through kube-state-metrics, or run a small watcher that pings an external monitor every 10 seconds while it is fresh.

[GitHub Actions monitoring](https://logdash.io/cron-monitoring/github-actions): GitHub shows you the runs that failed but never the runs that did not start, so watch a scheduled workflow from outside: the last step reports success, and a monitor alerts you when that report goes stale.

[Windows Task Scheduler monitoring](https://logdash.io/cron-monitoring/windows-task-scheduler): Task Scheduler keeps each task's last run time and last run result but never alerts on them, so monitor it with a small PowerShell watcher that pings an external monitor every 10 seconds while the last run is recent and clean.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.