RabbitMQ Health Check: The Ladder of Checks
A rabbitmq health check proves one thing at a time. Here is the ladder from ping to alarms, the HTTP endpoints, and the outage every ping survives.
A rabbitmq health check is a single command or request that tests one aspect of a broker node. There is no universal answer to "is RabbitMQ healthy", so the vendor documents a ladder of checks instead. Each rung costs more and proves more, and picking the wrong rung is how a blocked broker keeps passing.
The rabbitmq health check ladder, cheapest first
RabbitMQ's monitoring documentation frames health checking as increasing levels of intrusiveness. Start at the bottom and climb only until the check answers the question you actually have.
| Level | Command | Proves |
|---|---|---|
| 1 | rabbitmq-diagnostics ping | the node process is alive and responding |
| 2 | rabbitmq-diagnostics check_running | the node has fully booted and joined |
| 3 | rabbitmq-diagnostics check_local_alarms | no memory or disk alarm is active here |
| 4 | rabbitmq-diagnostics check_port_connectivity | every configured listener accepts a socket |
| 5 | rabbitmq-diagnostics check_virtual_hosts | no virtual host is down on this node |
Level 1 is what belongs in a restart policy. Levels 3 and 4 are what belong in a readiness gate. We prefer check_port_connectivity as the default for anything that decides whether traffic should arrive, because it catches the half-booted node that answers a ping and refuses AMQP.
Running the CLI checks
These commands run on the node, as a user with access to the Erlang cookie. Exit status is what matters, and the human-readable output is a bonus.
rabbitmq-diagnostics -q ping
rabbitmq-diagnostics -q check_running
rabbitmq-diagnostics -q check_local_alarms
rabbitmq-diagnostics -q check_port_connectivity
The -q flag drops the banner so the output is parseable. The diagnostics man page lists every subcommand, including the observer and listener inspections. Avoid rabbitmq-diagnostics status on a schedule. It gathers a full node report, including per-queue detail, and on a busy broker that is expensive enough to become the problem it was meant to detect.
The management plugin's HTTP endpoints
If the management plugin is enabled, the same checks are reachable over HTTP on port 15672. This is the version to use from a load balancer, an orchestrator or an external probe, because it needs no shell and no cookie.
curl -su guest:guest http://localhost:15672/api/health/checks/alarms
curl -su guest:guest http://localhost:15672/api/health/checks/port-listener/5672
curl -su guest:guest http://localhost:15672/api/health/checks/virtual-hosts
A healthy response is {"status":"ok"} with a 200. A failure returns 503 and a reason field naming what broke. There is also a quorum-critical check, which reports whether any quorum queue on the node is down to its last replica. Run that one before a rolling restart.
Use HTTP basic auth with a dedicated monitoring user rather than guest, which is restricted to localhost by default anyway. Give it the monitoring tag and no permissions on any virtual host. The endpoints then work from a load balancer or a remote probe without handing anything a password that can also publish.
Why is aliveness-test discouraged now?
Because it writes. Calling /api/aliveness-test/<vhost> makes the broker declare a queue, publish a message to it and consume that message back. It is a genuine end-to-end test, and running it every ten seconds means a queue churning permanently in your default virtual host.
It also passes in a situation where nothing else works. The aliveness queue is small and local, so it succeeds while real queues are refusing publishes. Use it as a deliberate deep check during an incident, not as the probe an orchestrator runs every interval.
Alarms are the failure everyone misses
A node that trips its memory high watermark or its free disk limit keeps running. It answers a ping, accepts connections and appears entirely normal in a dashboard. What it does is block every publishing connection until the alarm clears.
That is why check_local_alarms sits on the ladder at all. A rabbitmq health check that stops at ping will call this node healthy while producers hang. We tested it by filling the disk on a single-node broker: ping returned success for the whole outage, and the alarms endpoint returned 503 within one interval.
Alarms are node-local, so check them on every node rather than through one management URL. The four golden signals frame this as saturation, and saturation is the signal that liveness probes are worst at detecting.
The thresholds are configurable and the defaults are conservative. RabbitMQ's resource alarms reference documents the memory high watermark and the free disk limit, both settable in rabbitmq.conf. Raising them buys headroom and raises the odds the operating system kills the node instead, so move them deliberately.
Checking the broker from outside
Everything above runs inside the network. None of it proves that a client on another host can open an AMQP connection, which is the only thing your producers care about.
A tcp check against 5672 from outside the cluster closes that gap. It completes a real handshake over a real network path. A firewall change, a broken security group or a failed listener then shows up as a failure rather than as silence. Pair it with an http check on the management API so you can tell a dead broker from a dead box. Our write-up on watching TCP and UDP services covers the assertion options in more detail.
Run that check from more than one place. A rule that blocks one subnet leaves every other path working, and a single vantage point will not see it. Uptime Room runs probes in six regions as of September 2026, and the addresses you need to allow through a firewall sit on the probe IPs reference.
Common mistakes
Using status as the periodic check. It is the heaviest command in the toolbox. On a broker with thousands of queues it can take seconds and add real load, and a probe that slows the thing it watches eventually causes an incident.
Checking one node and calling it a cluster. Alarms, listeners and virtual host state are per node. A three-node cluster needs three checks, plus the quorum-critical check before you restart anything.
Alerting on the management UI instead of the broker. The UI is a plugin. It can be disabled, crash or be unreachable while messaging is fine, and it can also be perfectly healthy while publishers are blocked. Alert on what the check semantics actually mean.
A good rabbitmq health check climbs exactly as far as the decision needs. Ping for restarts, port connectivity and alarms for readiness, and the HTTP endpoints for anything outside the shell. Add one external check against 5672 so a network fault cannot hide behind green nodes. The free plan allows 10 monitors at a one-minute interval as of September 2026, which is enough for a small cluster, so start free.
FAQ
With the management plugin enabled, the health endpoints sit under /api/health/checks on port 15672. Useful ones are alarms, port-listener followed by a port number, protocol-listener, virtual-hosts and the quorum-critical check. Each returns a 200 with a status of ok when healthy, and a 503 with a reason field when it is not.
Run rabbitmq-diagnostics ping for the cheapest answer, which confirms the node process is alive and responding. Use check_running instead when you need to know the node finished booting rather than merely started. Both return a non-zero exit status on failure, so a shell script or an orchestrator can act on them without parsing the text output.
Almost always a resource alarm. When a node crosses its memory high watermark or its free disk limit, it keeps running and keeps answering a ping, but it blocks every publishing connection until the alarm clears. Only a check that inspects alarms, such as check_local_alarms or the alarms HTTP endpoint, reports that state as unhealthy.
Only as a deliberate deep check. It declares a queue, publishes a message and consumes it back, which makes it a genuine round trip but also a write on every call. Run every ten seconds it leaves a queue churning in your virtual host, and it can still pass while real queues are refusing publishes.
Related reading
- Port Monitoring: Check TCP and UDP Services - Port monitoring tells you a listener answered on host and port. Here is what that proves, what it does not, and which ports deserve a check.
- Golden Signals: The Four SRE Metrics That Matter - Golden signals are latency, traffic, errors and saturation - the four metrics Google's SRE book says to watch when you can only watch four.
- Downtime: What It Means and How to Measure It - Downtime is any period a system is unavailable, but the percentage only means something once you state where you measured from and what counted.