A RabbitMQ health check is one of those services that sounds like an upsell until you've had one done. The teams that get the most value from assessments are usually the ones who went in skeptical — convinced their deployment was stable — and walked out with a prioritized list of issues their monitoring had been missing for months.
This post explains what a RabbitMQ assessment actually covers, what you receive at the end, and the categories of findings that come up consistently regardless of deployment maturity.
What is a RabbitMQ health check or assessment?
A RabbitMQ health check is a fixed-scope technical review of your deployment. It's not a monitoring tool, not a pen test, and not a continuous service. It's a structured engagement where an expert examines your cluster configuration, topology, security settings, resource utilization, and operational patterns — and produces a findings report with prioritized recommendations.
AceMQ offers two primary engagement types:
Standalone health check / configuration audit: A one-time, fixed-scope review with no ongoing commitment required. Covers cluster health, queue topology, configuration settings, security baseline, load balancing, and resource sizing. Delivers a prioritized findings report. Typical scope is one to two weeks.
Discovery + architecture engagement: A broader assessment that includes the health check elements plus architectural recommendations, upgrade path planning, and an operational roadmap. Often used as the entry point before a migration, version upgrade, or new Kubernetes deployment.
What does a health check examine?
A complete RabbitMQ health check covers several layers of your deployment:
- 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
Across assessments of enterprise RabbitMQ deployments — from banks and utilities to SaaS platforms and healthcare systems — five categories of findings recur consistently:
1. Classic mirrored queues still in use. Organizations that deployed RabbitMQ before quorum queues were the default recommendation often still have classic mirrored queues for their critical workloads. Mirrored classic queues are deprecated (removed in RabbitMQ 4.x) and have known failure modes including split-brain scenarios.
2. Antivirus or security tools scanning RabbitMQ data directories. Endpoint protection tools that include the RabbitMQ data directories (
/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.3. Default credentials or over-permissioned users. The default
guest user or broadly permissioned administrative users appear in assessments more often than teams expect. Virtual host isolation is also frequently not implemented.4. Heartbeat and TCP timeout misconfiguration for cloud environments. The default RabbitMQ heartbeat and TCP timeout settings are tuned for low-latency local network environments. In cloud deployments — particularly across availability zones or with NAT gateways — these defaults cause false-positive connection drops and unnecessary client reconnects.
5. Under-provisioned or imbalanced clusters. Either clusters where three nodes are distributed across only two physical hosts (defeating anti-affinity), or clusters where memory or disk sizing doesn't match the actual working set. Memory high watermark settings are often left at defaults that don't reflect actual load patterns.
What do you receive at the end of an assessment?
A structured findings report organized by severity (critical, high, medium, low), with:
- 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
For engagements that include architecture scope, the deliverable also includes an architecture diagram, capacity planning guidance, and an operational roadmap.
Is the assessment useful if my deployment seems stable?
Usually yes — and stability is often what makes an assessment most valuable. Teams whose deployments are actively broken are focused on incident response. Teams with stable deployments have the bandwidth to actually implement recommendations, and often have lower-urgency issues that have been accumulating for months without creating an incident yet.
The most impactful assessments we've done were for clients who said "we're running well, we just want an expert set of eyes on it" — and discovered three-year-old configuration decisions that were silently limiting performance or creating security exposure.
Ready to schedule a RabbitMQ health check or discuss the scope of a discovery engagement? Contact our team for a conversation about what's right for your deployment.