Data Systems
    Updated May 2026
    RabbitMQ logo

    RabbitMQ Monitoring

    Monitor RabbitMQ queue depth (messages_ready / unacknowledged), publish/deliver/ack rates, memory & disk alarms, file descriptors, cluster partitions, and quorum queue state in real time — via the management HTTP API or `:15692` Prometheus endpoint.

    Start Free TrialView Docs

    Why monitor RabbitMQ?

    RabbitMQ is the broker behind Celery, Sidekiq, microservice eventing, and MQTT IoT pipelines. Queue saturation, memory and disk alarms (which block all publishers cluster-wide), and quorum queue leader-election storms cause processing delays or full broker outages. Monitoring catches the signals before stuck consumers and multi-million-message backlogs.

    Auto-discovery via Xitogent — no manual configuration required
    Real-time queue depth and message rate monitoring
    Consumer count and prefetch tracking per queue
    Node memory and disk usage alerts
    Exchange and binding performance metrics
    Dead letter queue monitoring
    Works on both Linux and Windows servers
    1-minute metric collection intervals
    What is RabbitMQ monitoring?

    RabbitMQ monitoring, explained

    RabbitMQ monitoring catches queue saturation (consumers can't keep up), memory + disk alarms (publishers get blocked), unacknowledged-message buildup (slow consumers), connection / channel leaks, cluster partition events, and quorum queue leader election issues before they cause message processing delays, full broker outages, or data loss. For Celery / Sidekiq task queues, microservice eventing, MQTT IoT ingestion, and any production RabbitMQ cluster, per-queue + per-node visibility is what separates a 60-second alert on a stuck consumer from finding 10M messages backed up tomorrow. Xitoring auto-discovers your RabbitMQ, reads the management API + Prometheus plugin, and routes alerts to Slack, PagerDuty, Telegram, or your existing on-call.

    Metrics

    What we monitor

    Queue Depth

    Number of messages ready and unacknowledged in each queue.

    Message Rates

    Publish, deliver, acknowledge, and redelivery rates per second.

    Consumer Count

    Number of active consumers attached to each queue.

    Node Memory

    Memory used by each RabbitMQ node including binary and queue memory.

    Disk Free Space

    Available disk space on each node against the configured alarm threshold.

    Connection Count

    Total client connections and channels across the cluster.

    Exchange Rates

    Message rates through each exchange (publish in/out).

    Unroutable Messages

    Messages that couldn't be routed to any queue.

    File Descriptors

    Used vs available file descriptors on each node.

    Erlang Processes

    Number of Erlang processes running on each node.

    Cluster Partitions

    Network partition events between cluster nodes.

    Dead Letter Messages

    Messages routed to dead letter exchanges due to rejection or TTL expiry.

    Triggers & Alerts

    Configurable alert triggers

    Set up custom triggers in your dashboard to get notified the moment RabbitMQ metrics cross your defined thresholds.

    RabbitMQ monitoring trigger configuration dashboard

    Queue Depth

    critical

    Fires when messages pile up in a queue, indicating consumers can't keep up with producers.

    Consumer Count

    warning

    Triggers when consumers drop below threshold, risking message processing delays.

    Node Memory

    critical

    Alerts when node memory approaches the high watermark, risking flow control activation.

    Message Rate

    warning

    Fires when publish or delivery rates deviate significantly from baseline.

    Disk Free Alarm

    critical

    Triggers when disk space drops below the configured threshold, blocking all publishers.

    Unacknowledged Messages

    warning

    Alerts when unacked messages grow, indicating slow or stuck consumers.

    01

    Importance of RabbitMQ Monitoring

    RabbitMQ is the backbone of event-driven architectures — handling order processing, notifications, data pipelines, and inter-service communication. Without monitoring, queue saturation, consumer failures, and memory pressure can cascade into full system outages.

    • Detect queue buildup before it causes application timeouts
    • Monitor consumer health to ensure message processing continuity
    • Track memory and disk usage to prevent flow control activation
    • Identify unroutable and dead-lettered messages early
    • Ensure cluster partition recovery for high availability
    RabbitMQ monitoring dashboard with queue depths and message rates
    RabbitMQ cluster health and dead letter queue monitoring
    02

    Why Choose Xitoring

    Xitoring delivers enterprise-grade RabbitMQ monitoring with zero-config setup. Our lightweight agent auto-discovers your RabbitMQ nodes, starts collecting metrics in under 60 seconds, and integrates with your existing notification channels.

    • One-command install — no complex YAML or config files
    • 15+ global monitoring nodes for low-latency checks
    • Unified dashboard for servers, message brokers, and uptime
    • Flexible alerting via Slack, PagerDuty, Telegram & more
    • Historical data retention for capacity planning & audits
    Xitoring RabbitMQ monitoring overview
    Alert notification and escalation configuration
    Use cases

    Common RabbitMQ monitoring scenarios

    Where RabbitMQ typically runs today — and what could go wrong if no one's watching.

    Background jobs in a web app

    Web apps push slow work — sending emails, generating PDFs, processing payments — to a background queue so the site stays fast. When that queue quietly backs up, those tasks are delayed for every user. We catch the backup early so the team can fix it before customers notice.

    The messaging backbone connecting your apps

    When messages pass between apps to keep data in sync, any slowdown means one app is silently falling behind. We catch the lag the moment it begins so it doesn't quietly grow into a customer-visible problem.

    Collecting data from IoT devices

    Smart devices and sensors send constant streams of data to a central server. When that pipeline gets stuck, data is silently dropped or delayed. We watch the flow so every device reading is accounted for.

    Before you start

    Prerequisites for RabbitMQ

    Make sure you've got these in place — most installs are a 60-second job once they are.

    • RabbitMQ 3.13.x or 4.x running with the management plugin enabled (port 15672) — OR rabbitmq_prometheus plugin enabled (port 15692)
    • A user with the monitoring tag for management API access
    • Network reachability from Xitogent to the management API and/or Prometheus endpoint
    Setup Guide

    Get started in minutes

    1

    Install Xitogent on your server

    If you haven't already, install the lightweight Xitogent monitoring agent on your server.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Enable the RabbitMQ management plugin

    Xitogent collects metrics via the RabbitMQ management API. Enable the plugin if not already active:

    rabbitmq-plugins enable rabbitmq_management
    3

    Enable the RabbitMQ integration

    Use the Xitoring dashboard or CLI to enable the RabbitMQ integration. Xitogent will auto-detect your instance.

    sudo xitogent integrate
    4

    Configure alert thresholds (optional)

    Set custom thresholds for queue depth, consumer count, or memory usage to get notified when something needs attention.

    5

    Verify it's working

    Run this command on the server to confirm Xitogent picked up the integration. Fresh metrics will start streaming to your dashboard within ~30 seconds.

    sudo xitogent status
    Compare

    Considering alternatives?

    See how Xitoring stacks up against the alternatives for RabbitMQ monitoring — flat pricing, deeper integrations, and one agent that covers your whole stack.

    See all comparisons

    Frequently asked questions

    What is RabbitMQ monitoring?
    RabbitMQ monitoring is the continuous collection of broker, node, queue, and consumer performance data — queue depth (`messages_ready` / `messages_unacknowledged`), publish/deliver/ack rates, consumer count + utilization, node memory + disk + file descriptors, alarms (memory high watermark, disk free limit), cluster partition events, and quorum queue leader state — combined with alerting on threshold breaches. It catches stuck consumers, memory alarms, and cluster partitions within the polling interval.
    How do I monitor queue depth in RabbitMQ?
    `messages_ready` (waiting for a consumer) and `messages_unacknowledged` (in-flight, sent to a consumer but not yet ack'd) are the two depth signals. Total `messages = ready + unacknowledged`. Ready growth = consumer can't keep up; unack growth = consumer is slow to ack (possibly stuck or processing too long). Track both separately. Threshold depends on use case — task queues should drain quickly (< 1000); event-stream queues may have larger sustained backlogs.
    How do I detect RabbitMQ memory and disk alarms?
    RabbitMQ raises `vm_memory_high_watermark` (default 40% RAM) and `disk_free_limit` (default 50MB, checked every 10s) alarms when thresholds breach — BOTH block all publishers across the entire cluster until cleared. Read alarm state from `/api/overview alarms` field or `rabbitmqctl status`. Alert immediately on any alarm; downstream applications will start seeing publish failures within seconds.
    What is the difference between classic, quorum, and stream queues?
    Classic queues: original queue type, non-replicated by default. Mirroring (classic mirrored queues) was the HA option but is removed in RabbitMQ 4.0. Quorum queues: Raft-based replicated queues, the modern HA replacement — durable, replicated, slightly higher latency. Streams: append-only persistent log queues (Kafka-like semantics), for replay and fan-out workloads. Monitor each type with its own metric semantics — quorum has leader-election state; streams have segment-based storage metrics.
    How do I monitor RabbitMQ cluster status and network partitions?
    `/api/nodes` returns per-node state (running, mem_alarm, disk_free_alarm, partitions array). Non-empty `partitions` = network partition — the cluster has split into multiple sub-clusters that disagree about state. Recovery strategy is configured via `cluster_partition_handling` (`ignore` / `autoheal` / `pause_minority` / `pause_if_all_down`). Alert on any non-empty `partitions` immediately — partitions can cause message loss with mirrored queues (less risky with quorum queues).
    How do I enable the Prometheus plugin in RabbitMQ?
    `rabbitmq-plugins enable rabbitmq_prometheus` enables the built-in Prometheus exporter (no separate sidecar). It exposes `/metrics` on port `:15692` by default. Scrape with Prometheus, or Xitogent — all read the same data. Built-in since RabbitMQ 3.8, mature and recommended over the legacy management-API polling for high-cardinality environments.
    What does the rabbitmq_management UI show?
    The web UI at `:15672` (after `rabbitmq-plugins enable rabbitmq_management`) shows overview (cluster state, message rates, alarms), per-node detail, per-queue depth + consumers + rates, per-exchange + binding view, per-connection + channel detail, user/vhost management. It's a great ad-hoc dashboard but not designed for continuous monitoring at scale — use Xitogent / Prometheus / for trending and alerts.
    RabbitMQ vs Kafka monitoring — what's different?
    RabbitMQ is queue-centric — `messages_ready` + `messages_unacknowledged` per queue, consumer count per queue. Kafka is log-centric — consumer group lag (current offset vs end-of-log) per partition, under-replicated partitions per broker. Different semantics: a Kafka consumer can read history; a RabbitMQ consumer can't. Different scale models: Kafka scales partitions; RabbitMQ scales via more queues or quorum-queue leader distribution. Use the appropriate integration for the appropriate broker.
    What RabbitMQ versions are supported?
    RabbitMQ 3.13.x (legacy stable, classic mirrored queues still available) and 4.0.x / 4.1.x (current, requires Erlang/OTP 26+, mirrored queues removed — quorum queues + streams are the only HA options). MQTT 5 plugin, STOMP, AMQP 1.0 all supported. Khepri metadata store (experimental Mnesia replacement) is detected and surfaced when enabled.

    Start monitoring RabbitMQ today

    Set up in under 60 seconds. No credit card required. Full metrics from day one.

    Start Free Trial

    Keep exploring

    Related Integrations