How to monitor

How to monitor RabbitMQ

RabbitMQ moves the messages your system depends on. When it's down or queues back up, work silently stops. Here's how to monitor RabbitMQ reachability, health and queue depth.

StatusCat3 min read

RabbitMQ is the plumbing that moves messages between your services. When it goes down, or when consumers stall and queues back up, work quietly stops — jobs don't run, emails don't send, events don't propagate — often with no obvious error. Monitoring the broker and the queues gives you an early warning.

Here's how to monitor RabbitMQ reliably, without exposing it publicly.

What to monitor

  1. Broker reachability — is RabbitMQ up and accepting connections?
  2. Broker health — can it actually serve? RabbitMQ exposes health-check endpoints via its management API.
  3. Queue depth — are messages piling up because consumers have stalled? This is the signal people most often miss.

Approach 1: TCP reachability (baseline)

A TCP check on the AMQP port (default 5672) confirms the broker is reachable when it's on a publicly-reachable host. If the broker is private, use the health + queue-depth heartbeat below instead.

Approach 2: Health + queue-depth heartbeat (stronger)

Run a small scheduled job inside your network that queries RabbitMQ's management API and only pings StatusCat when everything is healthy:

# Runs on a schedule inside your network.
# 1) broker healthy?  2) queue not backed up?
curl -fsS -u "$RMQ_USER:$RMQ_PASS" http://localhost:15672/api/healthchecks/node/ | grep -q '"status":"ok"' \
  && depth=$(curl -fsS -u "$RMQ_USER:$RMQ_PASS" http://localhost:15672/api/queues/%2f/your-queue | grep -o '"messages":[0-9]*' | cut -d: -f2) \
  && [ "${depth:-999999}" -lt 1000 ] \
  && curl -fsS -m 10 https://statuscat.co/ping/your-rabbitmq-id > /dev/null
  • The health check confirms the broker is serving.
  • The depth check fails the whole chain if a queue grows past your threshold (here, 1000 messages).
  • With &&, the StatusCat ping only fires when both pass — so "broker down" or "queue backed up" becomes a missing heartbeat, and you're alerted.

Tune the threshold to your normal queue behaviour, and add one heartbeat per critical queue.

What else to watch

  • Consumers — a heartbeat from each consumer confirms it's actually processing, not just connected.
  • The host — a TCP/ICMP check catches infrastructure failures.
  • Disk & memory alarms — RabbitMQ blocks publishers when these trip; surface them from inside via a failing heartbeat.

Put it together

A robust RabbitMQ setup is usually a health + queue-depth heartbeat, a TCP/host check, and per-consumer heartbeats. Wire alerts and escalation so the right person hears about it fast.

StatusCat supports TCP, ICMP, HTTP and heartbeat monitors, free for 50 monitors. New to monitoring? Start with what uptime monitoring is and how to monitor a cron job.

Frequently asked questions

What's the best way to monitor RabbitMQ health?
Use RabbitMQ's built-in health-check endpoints via its management API, checked by a heartbeat job inside your network, plus a queue-depth check that fails (stops the heartbeat) when a queue grows beyond a safe threshold. That catches both 'broker down' and 'consumers stalled.'
Can I check RabbitMQ without exposing the management API publicly?
Yes — keep the management API private and run a small scheduled job inside your network that queries it and pings StatusCat on success. If the job can't reach RabbitMQ or a queue is too deep, the ping stops and you're alerted.
Why monitor queue depth, not just whether RabbitMQ is up?
Because RabbitMQ can be perfectly healthy while your consumers have stalled — messages pile up and work stops, even though the broker is 'up.' A growing queue is often the first sign of a downstream failure.

Keep reading

GuidesHow to monitor SSL certificate expiry (and never get caught out)Expired TLS certificates cause instant, total outages — and they're completely preventable. Here's how certificate expiry monitoring works and how to set it up in minutes.GuidesHow to monitor an API (the right way)A 200 response doesn't mean your API works. Here's how to monitor an API properly — status, latency, payload correctness, auth and SSL — so you catch real failures before your customers do.GuidesHow to monitor a cron job (with heartbeats)Cron jobs fail silently — the job stops, the server reboots, a deploy breaks the schedule, and nobody notices until data is missing. Here's how heartbeat monitoring catches it.