RabbitMQ Health Check
A RabbitMQ health check is a senior engineer reading your cluster the way an incident would: version and patch position, topology and queue types, memory and disk alarms, partition handling, monitoring and client behaviour. You get written findings, a prioritised fix list, and the reasoning behind each one. Start with the free self-service check, or book the engineer-led assessment.
The only partner with 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 makes AceMQ the only RabbitMQ partner with a direct line to the core team. When an escalation needs an answer that is not in the documentation, it does not stop at a support tier.
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 130+ 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
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.
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. A RabbitMQ audit regularly turns up the same kinds of finding:
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.
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 300,000+ connected devices, 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 come back with a scoped price within 24 hours. 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 come back with a timeline and price within 24 hours. Or run the free self-service check first.
Send us a message and we'll follow up within one business day — 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.