Error

Connection blocked: low on disk / low on memory: what a RabbitMQ resource alarm does to your publishers

2026-10-19 · 2 min read · Viktor Baumann

connection.blocked: low on disk

When a node runs short of disk space or memory, RabbitMQ raises a resource alarm and blocks every connection that publishes. Consumers keep running, so the queues can drain. What your publishers notice depends on the client, and the default is to notice nothing. Measured on RabbitMQ 4.3.6 with pika 1.3.2, the alarm raised by setting the disk free limit above the free space.

What happened to the publisher

• The basic_publish call returned at once. The client had written the message to the socket; the broker did not read it.
• The connection received connection.blocked with the reason low on disk.
• With blocked_connection_timeout=5, pika gave up after 5 seconds with ConnectionBlockedTimeout and closed the connection. The message was not in the queue.
• A consumer on another connection could still read from the queue during the alarm.

Without a timeout (pika's default), the publisher waits until the alarm clears, however long that is: requests pile up in front of it, threads hang, health checks that only look at "connected" stay green.

What to do

• In the client: set a blocked-connection timeout and treat it as a failed publish, or register the blocked/unblocked callbacks and stop publishing while blocked. Use publisher confirms: a message is only safe once it is confirmed.
• Separate connections for publishing and consuming. A blocked connection blocks consumers on it too; on a separate connection they keep draining the queues, which is what ends the alarm.
• In the broker: find what fills the disk. Usually it is a queue nobody consumes, or a dead-letter queue that only grows. rabbitmq-diagnostics alarms shows the active alarm; disk_free_limit and vm_memory_high_watermark are the thresholds.