RabbitMQ Health Check
Last reviewed by Tyler Eastridge
A RabbitMQ health check is a senior engineer's review of your cluster: version and CVE position, topology and queue types, memory and disk alarms, partition handling, monitoring and client behaviour. You get a written report with every finding ranked P1 to P3 and a fix plan. Start with the free self-service check, or book the engineer-led assessment.
Direct RabbitMQ core-team access
Customers
Partners
Named by the RabbitMQ Core Team
AceMQ is the Featured Authorized Partner for RabbitMQ, named by the RabbitMQ Core Engineering Team — the people who write and maintain the broker. That recognition covers RabbitMQ support, licensing and professional services, and it gives AceMQ direct RabbitMQ core-team access. When an escalation needs an answer that is not in the documentation, it does not stop at first-line support.
You do not have to take our word for it — RabbitMQ lists AceMQ on its own site.
See AceMQ listed on rabbitmq.com (opens in a new tab)Is This You?
The cluster has been stable for a while and nobody can say why, or what would change that
An upgrade, migration or platform move is coming and you want to know what it will hit
Memory or disk alarms fire occasionally and get cleared without anyone finding the cause
Classic mirrored queues are still in production and the deprecation date is a known unknown
The people who designed the topology have moved on and the diagram is out of date
An auditor or vendor questionnaire is asking about patch level, CVE exposure or DR posture
You are choosing between support, managed services and an upgrade, and want the facts before the contract
Outcomes
Concrete state changes, not deliverable counts. This is what actually differs about your RabbitMQ estate when the engagement closes.
Before
The cluster's version, patch level and CVE exposure are known approximately, from memory.
After
A written inventory per node and per cluster, checked against the published CVE register, with what to patch first.
Before
Queue types, policies and HA settings were chosen at go-live and never revisited.
After
Every queue type and policy reviewed against the workload it carries, with the classic-to-quorum candidates listed.
Before
Alerts exist for whatever the last incident was. Nothing watches the next one.
After
A monitoring gap analysis against the ten failure patterns we see most, with the thresholds written down.
Before
The team knows something is fragile but cannot rank the risks or cost the fixes.
After
A prioritised remediation list with effort, risk and sequencing, usable as a plan or as a procurement basis.
Scope
RabbitMQ and Erlang versions per node, distance from the current patch release, and exposure against every published advisory. Where a series is past community end of life, the realistic options are set out rather than assumed.
Exchanges, bindings, vhosts and policies read against the workload. Classic, mirrored, quorum and stream queues checked for fit, with delivery limits, dead-lettering and overflow behaviour reviewed queue by queue.
Memory watermark, disk free limit, file descriptors, Erlang process and scheduler headroom. Sizing checked against sustained and peak rates, not the numbers guessed at go-live.
Node count and placement across failure domains, partition-handling mode, net_ticktime and heartbeat settings against the real network, and whether failover has ever actually been tested.
What is measured, what is alerted, and what would have caught the last three incidents. Prometheus and Grafana coverage checked against queue depth, unacked counts, connection churn and partition status.
Prefetch, acknowledgement, connection and channel reuse, confirms and automatic recovery in the applications that talk to the broker. Most cluster symptoms start on the client side.
The Engagement
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
Run the free health check at assessment.acemq.com against your management API. It produces a report on cluster health, queue depths, consumer lag, node resources and policy compliance. Many teams stop here; the engineer-led assessment starts from this report rather than repeating it.
You receive
We agree scope, clusters in and out, and the read-only access we need. Screen-share is the default; we take no system access and store no client data, which is why regulated teams are comfortable with it.
You receive
A senior engineer works through the six scope areas against your actual configuration, metrics and client code, with your team in the room where it helps. Findings are checked against the failure patterns we see most across 160+ estates.
You receive
A written report and a walkthrough with the engineer who did the work. Every finding carries the fix, the effort and the risk of leaving it, sequenced into a plan you can execute yourselves, with us alongside, or hand to a support or managed-services contract.
You receive
We have delivered 20+ assessments and architecture reviews since mid-2025 across RabbitMQ, Kafka, Redis and IBM MQ, and most engagements start with an assessment. The table below is a sample from the finding catalogue our engineers write reports against, with the severity we assign. Each finding was recorded on more than one customer estate; none is tied to a named customer here.
| ID | Finding | Severity | What it means in practice |
|---|---|---|---|
| V-1 | Running a RabbitMQ version past community end of life | Critical (P1) | No patch route for the broker. Options are an upgrade or a supported extended-support build. |
| T-4 | Classic mirrored queues in use | High (P2) | Deprecated in 3.13 and removed in 4.x, so they block the upgrade path and recover inconsistently after a node loss. |
| T-5 | Partition handling left at the default, ignore | High (P2) | After a network split both sides can accept writes and diverge. |
| Q-1 | Non-durable queues carrying business-critical data | Critical (P1) | A broker restart empties the queue. |
| Q-2 | No maximum length on application queues | High (P2) | A stalled consumer lets the queue grow until the memory alarm blocks every publisher. |
| Q-4 | Consumer prefetch unlimited with slow consumers | High (P2) | Unacknowledged messages pile up in memory on the node the consumer is connected to. |
| M-1 | Memory watermark above 0.7 on a shared host | High (P2) | Little headroom for the operating system, so an alarm turns into an out-of-memory kill. |
| S-1 | Default guest user reachable from outside localhost | Critical (P1) | A well-known credential on the management and AMQP ports. |
| S-2 | TLS not enabled on the AMQP port | High (P2) | Credentials and message bodies cross the network in clear text. |
| O-2 | No alerting on memory or disk alarms | High (P2) | Publishers are blocked and nobody is paged. |
| O-4 | No definitions export or backup process | High (P2) | Rebuilding the topology after a loss depends on memory. |
| O-5 | No tested rollback procedure for upgrades | High (P2) | A failed upgrade has no rehearsed way back. |
Severity follows three levels. P1 (critical) is an active risk of data loss or outage. P2 (high) is a significant risk that should be fixed soon. P3 (medium) is a best-practice gap with low risk. Two more patterns appear on most estates: LDAP in the client authentication path, so a directory outage becomes a broker outage, and shared clusters, where one team's workload sets the failure risk for every other team.
What we do not do
We deliver assessments remotely, guided by your engineers over screen share. We do not access your environments or code, and any remediation work beyond the assessment is time and materials.
These 20 checks are the core of a RabbitMQ health check. The self-service check at assessment.acemq.com covers the ones that can be read from the management API; the engineer-led assessment adds the rest, such as client code, failover behaviour and network rules.
The report is written, and the engineer who did the work walks you through it rather than sending a PDF. It contains:
No price is listed on this page because it depends on the number of clusters and the depth of review. Send the cluster count and we reply within 1 hour and follow with a scoped price, and the assessment is folded into onboarding if it leads into a support contract.
A RabbitMQ performance tuning review checks five things first, because they explain most slow or unstable clusters: consumer prefetch, publisher confirms, queue type, memory and disk alarms, and connection churn. This is how to optimize RabbitMQ without guessing. Each item is read against your own metrics and client code, not against defaults.
| Area | What we check | Why it matters |
|---|---|---|
| Consumer prefetch | The prefetch value and acknowledgement mode of every consuming application | Values from 100 to 300 usually give the best throughput without overwhelming consumers. A prefetch of 1 cuts throughput sharply. With manual acknowledgements and unlimited prefetch, unacknowledged messages grow memory use on the node the consumer is connected to. |
| Publisher confirms and batching | Whether publishers use confirms, and whether they wait on every message or handle confirms asynchronously or in batches | Asynchronous or batched confirms keep throughput up. AMQP transactions are far heavier: the documentation puts the cost at a factor of 250 in throughput. |
| Queue type choice | Classic, quorum and stream queues against the workload each one carries | Classic queues are not replicated. Quorum queues suit long-lived queues that need high availability. Very long backlogs, 5 million messages or more, and large fanouts suit streams. |
| Memory and disk alarms | Memory watermark and disk free limit against real usage, and whether alerts fire before the limit | When memory or free disk crosses its limit, connections that publish are blocked. An alarm is a publisher outage. |
| Connection churn | Rates of opened and closed connections and channels | Opening and closing connections consistently above 100 per second likely indicates a suboptimal setup. Long-lived connections are the fix, with TCP stack tuning where short-lived clients are unavoidable. |
The output is a ranked list of changes, each with the metric that will show whether it worked.
Customer Success
See how enterprises trust AceMQ for their most critical RabbitMQ workloads.
Global Automotive Manufacturer
Replacing fragile SQL-trigger-based ingestion with a reliable event-driven architecture for plant-floor data movement and low-latency operations.
RabbitMQMQTT
KafkaSQL Server
KubernetesFortune 500 Financial Services Company
Improving RabbitMQ reliability, queue behavior, and operational guidance for a payment system processing over 200 production changes weekly.
RabbitMQ
AWS
Spring AMQPQuorum QueuesGlobal Aviation Technology Provider
Troubleshooting cluster failover, partition handling, and quorum queue issues in a high-stakes aviation operational environment.
RabbitMQKubernetesQuorum Queues
Prometheus
GrafanaState-Run Virtual Education Platform
Standardizing RabbitMQ deployment and training staff while migrating infrastructure from VMware to Nutanix.
RabbitMQNutanix
Red HatPrometheusGrafana
DockerInternational Payment Exchange Service
Reducing manual error-queue operations by improving retry handling, dead-lettering, and downstream flow management across RabbitMQ, BizTalk, and D365.
RabbitMQBizTalkD365
IBM MQFortune 500 Software Company
Migration to supported RabbitMQ versions with managed services, standardization, compliance posture, and Tanzu commercial licensing.
RabbitMQTanzu RabbitMQAWSEKSKubernetesGlobal Telecom Leader
Resolving weekly RabbitMQ crashes, optimizing for a large connected-device fleet, and architecting horizontal scaling strategy.
RabbitMQKubernetesQuorum QueuesPrometheusGrafanaFortune 500 Industrial Conglomerate
Enterprise-grade RabbitMQ support with code-level remediation and patch management for regulated production environments.
RabbitMQFAQ
An engineer-led review of a production RabbitMQ estate: version and CVE position, topology and queue types, resource alarms and sizing, clustering and partition handling, monitoring coverage and client behaviour. The output is a written findings report with a prioritised fix list. It is distinct from the broker's built-in health probes, which report whether a node is up, not whether the cluster is designed to stay up.
No. RabbitMQ exposes HTTP health endpoints under /api/health/checks/ (for example alarms, local-alarms, node-is-quorum-critical) and the rabbitmq-diagnostics command for liveness and readiness probes. Those tell an orchestrator whether a node is serving. This page is the assessment service that reads the whole estate and tells you what will break next.
Yes. The free self-service check at assessment.acemq.com runs against your management API and returns a report on cluster health, queue depths, consumer lag, node resources and policy compliance, with nothing to install. The engineer-led assessment picks up where that report stops: the reasoning, the client-side causes and the plan.
The self-service check takes minutes. The engineer-led assessment takes one to four weeks, depending on how complex the estate is, which areas you want covered, and how many problems we find along the way. Intake is a day, and the findings walkthrough follows the assessment. We give a fixed timeline once we know the cluster count and focus areas.
It is priced on the number of clusters and the depth of review, not per node or per queue. Send the cluster count and we will reply within 1 hour and follow with a scoped price. Where the assessment leads into a support or managed-services contract, the assessment is folded into onboarding rather than charged twice.
The same handful of patterns across most estates: classic mirrored queues carrying workloads that need quorum queues, unbounded prefetch and slow acknowledgements, connection and channel churn from client code, a partition-handling mode that was never set, alerting that only covers the last incident, and a version several patch releases behind with disclosed CVEs. The failure-patterns guide on our resources page lists all ten with the fixes.
No. The health check is a standalone engagement. It is also the first phase of every support and managed-services onboarding, so if you go on to either, the work is not repeated.
Let's talk
Tell us how many clusters you run. We will scope the assessment and reply within 1 hour and follow with a timeline and price. Or run the free self-service check first.
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.