What is a RabbitMQ health check or assessment?
What does a health check examine?
- Cluster topology and node health. Node count, distribution across hosts or availability zones, disk and memory usage per node, and whether quorum queue leader distribution is balanced.
- Queue configuration and type. Whether you're running quorum queues or classic queues for workloads that require high availability, whether mirrored classic queues still exist, queue depth patterns, and consumer lag.
- Security configuration. Default credentials removed or changed, TLS enabled, virtual host isolation, user permissions scoped appropriately, and audit logging.
- Performance and load balancing. How connections are distributed across nodes, whether publisher flow control is triggering under normal load, and prefetch configuration relative to actual consumer throughput.
- Resource sizing. Whether node memory and disk allocation is appropriate for current queue depths and message rates, and whether sizing leaves headroom for burst traffic.
- Erlang and RabbitMQ version. Whether the current version is within the supported community window, what the upgrade path looks like, and whether any known CVEs apply.
- Operational configuration. Heartbeat settings, TCP timeout configuration, persistence policies, dead-letter queue setup, and message TTL configuration.
The five things assessments almost always find
/var/lib/rabbitmq) in their real-time scan scope are one of the most common causes of unexplained performance degradation. The fix is simple — exclude those directories — but it's frequently missed.guest user or broadly permissioned administrative users appear in assessments more often than teams expect. Virtual host isolation is also frequently not implemented.Where that leads next: designing a future-state RabbitMQ architecture, and if the estate spans several vendors, consolidating infrastructure support.
What do you receive at the end of an assessment?
- A clear description of each finding and why it matters
- Specific remediation steps — not vague recommendations, but the actual configuration changes or actions needed
- A prioritized sequence for addressing findings, based on risk and effort
- An upgrade path recommendation (if applicable to your current version)
- A summary of current cluster health suitable for sharing with management
Is the assessment useful if my deployment seems stable?
What the assessment finds most often
Across more than 130 enterprise engagements in 26 countries, the same findings keep coming back. Most of them are cheap to fix once they are named, and most of them are invisible until something fails. These are the ones we write up most often.
Classic mirrored queues still in use ahead of 4.x. Classic queue mirroring was removed in RabbitMQ 4.0, so a cluster that still relies on ha-mode policies has no upgrade path until those queues move. Mirrored queues also have the weakest failure behavior of the available types. The fix is a per-queue migration to quorum queues, with streams for the few workloads that need replay. Our comparison of classic and quorum queues covers where each belongs.
No publisher confirms on flows that cannot lose messages. Without confirms a publisher treats a successful TCP write as delivery, and messages vanish silently during a node failure or a memory alarm. We see this most on order, payment and billing flows, which are exactly the ones that cannot afford it. The fix is confirm mode on those channels with a retry on nack, and it is usually a small code change.
Unbounded queues with no length limit or TTL. A queue with no max-length and no TTL grows until it triggers a memory or disk alarm, and at that point every publisher on the cluster is blocked, not just the one feeding that queue. The fix is a policy that sets max-length or message TTL, with an overflow behavior the application owner has agreed to.
Prefetch left at default or unlimited. An unlimited prefetch lets one consumer pull a queue into its own memory while its siblings sit idle, and it turns a consumer crash into a large redelivery. The fix is a prefetch value matched to the consumer's processing time, typically somewhere between 10 and a few hundred.
A single hot queue carrying most traffic. A queue runs as one Erlang process on one node, so a single queue with most of the cluster's throughput caps the whole cluster at one core. The fix is sharding across several queues with consistent-hash or direct routing, or a stream if the consumers can work with an offset-based model.
Feature flags never enabled after upgrades. Feature flags gate the on-disk and inter-node formats. Clusters that were upgraded across several minor versions often have flags still disabled, which blocks the next major upgrade outright. The fix is to enable all stable flags once every node is on the same version, and to confirm that before planning the 3.x to 4.x move.
Erlang version behind the supported matrix. Every RabbitMQ release supports a narrow range of Erlang/OTP versions, and an unsupported pairing is the first thing any support case will be asked to correct. The fix is aligning Erlang with the target RabbitMQ version, usually in the same maintenance window as the broker upgrade.
No dead-letter consumer or alert. Dead-letter exchanges are usually configured. What is missing is anything that reads them. Messages accumulate for months, and the first time anyone looks is during an incident. The fix is a consumer, or at minimum an alert on dead-letter queue depth, as described in our dead-letter queue guide.
Alarms firing with nobody watching. Memory and disk alarms fire, publishers block, and the team learns about it from the application side. The fix is routing alarm and node-down events into whatever the team already pages on, with thresholds that leave room to act.
Definitions never exported. Exchanges, queues, bindings, users and policies exist only inside the running cluster, so rebuilding it after a disaster means rebuilding from memory. The fix is a scheduled definitions export into version control, which also makes drift between environments visible.
How the engagement runs, and what you get
A health check is a fixed-scope engagement with a defined start and end. It runs in four steps.
Kick-off and access. A short call to agree the scope, name the contacts, and set up read-only access to the management interface and metrics. Nothing on the cluster is changed at any point in the engagement.
One to two weeks of data collection and interviews. We pull definitions, policies, node and queue metrics, logs and version details, and we talk to the people who own the platform and the applications on it. The interviews matter because the metrics show what the cluster is doing, not what it is supposed to do.
A findings review with the team. Before the report is final we walk through the findings with the client, confirm each one against what the team knows, and settle the priority order together.
The written report. It contains prioritized findings with a severity for each, a remediation plan the team can run without us, a capacity and version position, and a go/no-go view on the next upgrade. The remediation plan is written as ordered work items with a reason for each, not as a list of best practices.
From the client side we need one platform owner, one application owner, and read-only management access. The cost in the client's time is a few hours in total: the kick-off, one or two interviews, and the findings review.
After the report there are two paths. The team runs the plan on its own schedule, or AceMQ runs it under a RabbitMQ consulting engagement or as part of a support contract, which also brings a 15-minute P1 response for the cluster going forward. Neither is assumed. Having a partner review the architecture is normal practice for a system this central, and the review does not commit you to anything further. Teams that want to see what a sound target looks like before they start can read our production RabbitMQ architecture guide.
To book the engineer-led version, or to start with the free self-service report, see the RabbitMQ health check service.
FAQ
Can a RabbitMQ partner review our architecture?
Yes. Architecture review is the core of a RabbitMQ health check, and it is how most engagements with AceMQ begin. As Broadcom's exclusive strategic RabbitMQ MSP partner we review clusters running anything from 3.8.x to 4.x, on premises or in any cloud, using read-only access only. The review covers topology, queue types, policies, client behavior, monitoring and upgrade readiness, and it ends in a written report the team owns. It does not require a support contract and does not commit you to one.
Do we need RabbitMQ architecture consulting?
Not always. If the cluster is on a supported version, the queue types match the workloads, confirms and prefetch are set deliberately, and someone is watching the alarms, you are probably fine. If any of those are unknown, or a 4.x upgrade is coming and nobody can say whether the cluster is ready, a health check answers the question cheaply. Most teams find the assessment alone covers what they needed, and only some go on to a larger consulting engagement.
How long does a RabbitMQ health check take?
Two to three weeks end to end for a typical environment. Kick-off and access take a day or two, data collection and interviews run one to two weeks, and the findings review and written report follow within a few days. Larger estates with many clusters or several environments take longer, and we say so in the quote. The client's own time commitment is a few hours across the whole engagement. An active outage is handled under support first, with a 15-minute P1 response, and the assessment follows once the cluster is stable.
What does a RabbitMQ assessment cost?
It is scoped by the number of clusters and the number of environments, and we quote within 24 hours of a scoping call. It is usually the cheapest engagement AceMQ runs, because the scope is fixed, nothing is changed on the cluster, and the output is a report rather than an implementation. Remediation, if you want us to do it, is quoted separately under consulting or support, and many teams run the plan themselves.