Knowledgebase

An unmonitored message queue can silently accumulate a backlog, drop messages, or run out of resources long before anyone notices — often surfacing only when users report missing emails, delayed notifications, or stalled background processing.

Key Metrics to Monitor

Monitoring RabbitMQ

Check queue depth via the management API:

curl -u admin:password http://localhost:15672/api/queues

Or via the CLI:

sudo rabbitmqctl list_queues name messages consumers

Monitoring Redis-Based Queues

redis-cli LLEN job_queue

For BullMQ specifically, use Bull Board (a dashboard UI) for visual monitoring of job counts, failures, and processing rates.

Setting Up Alerts for Growing Queue Depth

sudo nano /usr/local/bin/check-queue-depth.sh

#!/bin/bash
DEPTH=$(redis-cli LLEN job_queue)
THRESHOLD=1000

if [ "$DEPTH" -gt "$THRESHOLD" ]; then
    echo "Queue depth is $DEPTH, exceeding threshold of $THRESHOLD" | mail -s "ALERT: Queue Backlog" [email protected]
fi

sudo crontab -e

*/5 * * * * /usr/local/bin/check-queue-depth.sh

Integrating with Prometheus/Grafana

RabbitMQ has a native Prometheus plugin:

sudo rabbitmq-plugins enable rabbitmq_prometheus

Add it as a Prometheus scrape target, then build Grafana dashboards visualizing queue depth, message rates, and consumer counts over time — see How to Set Up Prometheus and Grafana for VPS Monitoring.

Monitoring Consumer/Worker Health

Beyond the queue itself, monitor that worker processes are actually running:

ps aux | grep worker

Or, if running as systemd services, monitor their status directly:

sudo systemctl status myapp-worker

Handling a Growing Backlog

1. Confirm consumers are actually running and processing
2. Check for individual jobs that are stuck or failing repeatedly, blocking progress
3. Scale up the number of worker instances if genuinely under-provisioned for current volume
4. Investigate whether the production rate has genuinely increased, or whether this indicates a real problem

Monitoring Dead-Letter Queues

A growing dead-letter queue (jobs that failed repeatedly and were set aside) indicates a systemic problem with either the jobs themselves or a downstream dependency — investigate rather than letting it silently accumulate.

Setting Up Health Checks for the Broker Itself

curl -f http://localhost:15672/api/healthchecks/node || echo "RabbitMQ unhealthy"

Integrate this into your broader uptime monitoring — see How to Set Up Uptime Monitoring for Your Website.

Common Errors

Queue depth climbing steadily with no plateau — consumers aren't keeping pace with producers; either scale consumers or investigate why processing has slowed.

Consumer count shows zero despite workers "running" — workers may have lost their connection to the broker; check worker logs and broker connectivity.

Best Practices

• Set proactive alerts on queue depth, not just broker uptime
• Monitor dead-letter queues specifically, since they indicate real processing failures
• Integrate queue metrics into your broader monitoring dashboard, not as a separate isolated tool

Related Articles

• How to Install and Configure RabbitMQ on a VPS
• How to Set Up Prometheus and Grafana for VPS Monitoring
• How to Set Up Effective Server Alerting (Without Alert Fatigue)