rabbitmqctl status: Broker Health in CI
rabbitmqctl status prints node health, listeners, and memory, while rabbitmqctl ping and await_startup give clean exit codes for CI readiness gates.
A RabbitMQ service container reports healthy on the TCP port before it can actually serve AMQP. rabbitmqctl gives node-level readiness checks that avoid that race.
What it does
rabbitmqctl status reports the running node: listeners, memory, disk, and plugins. ping returns exit 0 if the node responds. await_startup blocks until the node has finished booting, which is the reliable readiness signal for CI.
Common usage
rabbitmqctl status
# fast liveness check (exit 0 if the node answers)
rabbitmqctl ping
# block until the broker has fully started
rabbitmqctl await_startup
# as a service-container health check
docker exec rabbitmq rabbitmqctl await_startupOptions
| Command | What it does |
|---|---|
| status | Full node status report |
| ping | Exit 0 if the node is reachable |
| await_startup | Block until the node finishes booting |
| node_health_check | Deprecated broader health check (older versions) |
| -n <node> | Target a specific node name |
In CI
Prefer await_startup over polling the TCP port: the port opens before queues and the management plugin are ready, so a port check passes too early. Wire await_startup (or ping in a retry loop) into your service container health check so tests only start once RabbitMQ truly is up.
Common errors in CI
"Error: {:badrpc, :nodedown}" means the node is not running yet or the node name does not match; wait and confirm you target the right -n node. "Hostname mismatch" or an Erlang cookie error means rabbitmqctl is not talking to the local node; run it via docker exec inside the broker. status printing warnings about low memory or disk alarms explains why publishers get blocked.