The RabbitMQ Monitoring and Alerting Guide

The built-in rabbitmq_prometheus plugin exposes cluster metrics on 15692 in a form built for scraping. Teams that poll the management HTTP API instead end up adding measurable load to the broker they are trying to observe, particularly on clusters with many queues, where the API aggregates on request.

Enable the plugin, scrape it on a normal interval, and keep enough retention to see a week-over-week trend. Most useful alerts compare now against an hour ago, so a monitoring stack with only current values cannot express them.

A queue holding fifty thousand messages is normal for a batch workload and an emergency for a request-reply one, so an alert on absolute depth either pages constantly or never. What matters is publish rate exceeding consume rate for long enough that the backlog will not clear on its own.

Alert on sustained growth over a rolling window, per queue, with the window matched to how bursty the workload is. Keep absolute depth on the dashboard for context during the incident.

Unacked climbing while consumers stay connected is the clearest early warning RabbitMQ gives: consumers are taking messages and not finishing them. It appears well before the queue looks stuck, and it is the metric that distinguishes a slow consumer from an absent one.

Alert on sustained unacked growth, and pair it with per-consumer prefetch, because an unbounded prefetch lets a single consumer hold a large backlog in flight and turns its crash into a redelivery storm.

A queue with zero consumers produces no errors. Publishers keep succeeding, depth grows slowly, and nothing surfaces until the backlog is large or a TTL starts discarding messages. Deployments that fail to reconnect are the usual cause, and they fail silently.

Record the expected consumer count per queue and alert on any queue below it. This is one of the few RabbitMQ alerts worth having as an absolute threshold rather than a trend.

When RabbitMQ crosses its memory high watermark or its free disk threshold, it blocks publishers cluster-wide. By the time the alarm fires, the outage has already started, so an alert on the alarm itself is a notification rather than a warning.

Alert on approach instead, at a margin that leaves time to act, and treat repeated approaches as a sizing finding rather than an operational one. On virtualised infrastructure watch CPU steal and disk await alongside, because contention produces the same symptoms without the same cause.

Connection and channel counts that climb steadily are a client-side defect, not a broker one: an application opening a connection per message, or failing to close channels. The symptom presents as a RabbitMQ memory leak, and the fix is almost always in the application.

Trend both counts plus file descriptors and Erlang processes, alert on the trend and on an absolute ceiling below the configured limits, and use the connection metadata to identify which client is responsible before the descriptors run out.

A quorum queue that has lost its majority stops accepting writes by design, and a network partition can leave the cluster in a state no single node reports as unhealthy. Neither is visible from the application until publishes start failing.

Alert on any quorum member unavailable, on node-down, and on partition state, with no delay and no threshold. These are the RabbitMQ alerts that should always page.

Running on Kubernetes adds failure modes the broker metrics do not cover: pod eviction, node drain without a graceful RabbitMQ shutdown, storage class latency, and memory limits set below what the node needs under load. A cluster can look healthy in RabbitMQ's own metrics while the scheduler is removing it underneath.

Monitor pod restarts, eviction events and persistent volume latency alongside the broker metrics, and make sure a node drain triggers a graceful broker shutdown rather than an eviction.

Monitoring produces an alert; someone has to act on it. Estates that get this far and still have long incidents usually have alerts routing to a channel nobody is paged from, or to an engineer who owns the application rather than the broker.

Route the eight paging signals into whatever your team already wakes up for, keep everything else on a dashboard, and confirm the on-call path with a test alert rather than assuming it. Where there is no in-house RabbitMQ on-call, that is the gap a support contract fills.