Monitor BullMQ Repeatable Jobs
BullMQ's repeatable jobs are Redis-backed, so the failure modes differ from node-cron's in-process scheduling — a stalled worker, a Redis connection drop, or a repeatable job definition silently lost after a Redis flush.
Setup
Create an incoming monitor
Add a heartbeat monitor in Pingtastic matching the repeatable job's interval.
Ping inside the worker's processor function
After the job's real work completes, call the ping URL before the processor returns.
const { Worker } = require('bullmq');
new Worker('reports', async (job) => {
// ...existing job logic...
await fetch('https://ping.pingtastic.net/ping/nightly-report-queue');
}, { connection });Gotchas
- ⚠Repeatable jobs are stored in Redis, not in your code — if Redis is flushed, or you alter a repeatable job's cron pattern without removing the old definition first, you can end up with zero, or duplicate, scheduled runs. Check queue.getRepeatableJobs() if run counts look off.
- ⚠A worker process crash leaves jobs queued but unprocessed rather than failing loudly — a heartbeat ping (which only fires once a job is actually dequeued and run) catches this; process-uptime monitoring alone would not.
Questions
Does this apply to plain Bull (not BullMQ) too?
The same pattern — ping inside the processor function after the job completes — works for both. BullMQ is the actively maintained successor to Bull, but the monitoring approach is identical.
What if I redeploy and accidentally re-register the repeatable job with a different cron pattern?
BullMQ keeps both the old and new repeatable job definitions active unless you explicitly remove the old one — watch for jobs firing more often than expected as a sign this has happened.
Related guides
Start monitoring your Node.js bullmq / bull
Set up your first monitor in under five minutes.
Get started — $5/month