$ guides / rabbitmq / rabbitmq-consumer-utilisation-low ▌

Operations Guides

RabbitMQ consumer_utilisation low: consumers attached but not keeping up

The queue has messages. It has consumers. And yet the backlog keeps growing. The management UI shows consumer_utilisation (renamed consumer_capacity in newer RabbitMQ versions) at 0.2 or 0.3, and your first instinct, “just add more consumers”, may or may not be the right move.

consumer_utilisation is a per-queue estimate from the broker: the fraction of time the queue was able to deliver a message immediately to a waiting consumer. A value of 1.0 means every time a message was ready, a consumer could take it. A value below 0.5 with a non-empty backlog means the queue had messages sitting ready while no consumer was in a position to accept them. The bottleneck is on the delivery path between the queue and the consumers, not on publishing, and not on routing.

This guide covers how to read the metric correctly, how to tell slow processing apart from prefetch starvation and network latency, and which fixes actually move the number.

What this means

A queue delivers a message only when two things are true at the same time: the queue has a message ready, and at least one consumer has a free prefetch slot. consumer_utilisation measures how often that overlap happened. Low utilisation with messages_ready > 0 means the queue was ready to push but the consumers were not ready to receive, repeatedly.

Three mechanisms produce that state:

Consumers are busy processing. Each consumer holds unacknowledged messages up to its prefetch limit. While it processes, those slots are occupied. If processing is slow (a downstream database, an external API, a GC pause), slots stay occupied and the queue cannot push more.
Prefetch is too low. With prefetch set to 1, a consumer can hold exactly one unacked message. It receives a message, processes it, acks, and only then gets the next one. The round trip between ack and next delivery is dead time on the queue side. RabbitMQ’s own benchmarking showed that with prefetch 1 over localhost, consumer utilisation sat around 14%; raising prefetch to 30 brought it to roughly 70% before network bandwidth became the ceiling.
Latency between broker and consumer. Even with adequate prefetch and fast processing, every ack and every delivery crosses the network. High broker-to-consumer RTT shrinks the effective delivery window.

Two reading rules before you act on the number:

The metric is only meaningful when messages_ready > 0. An idle queue has nothing to deliver, so there is no delivery failure to measure. The Prometheus exporter reports NaN for idle queues because the underlying computation is undefined with zero deliveries; rabbitmqctl list_queues reports 1.0 for the same queue. Neither is a bug.
The field may be absent or not exposed for quorum queues in some RabbitMQ versions. If the field is missing on a quorum queue, fall back to deliver/ack rates and unacked counts instead of assuming consumers are fine.

flowchart TD
  A[consumer_utilisation low with backlog] --> B{messages_ready > 0?}
  B -- no --> C[Idle queue - metric not meaningful, stop here]
  B -- yes --> D{unacked near consumers x prefetch?}
  D -- yes --> E[Consumers saturated - check processing time and downstream deps]
  D -- no --> F{prefetch very low?}
  F -- yes --> G[Prefetch starvation - ack round trip dominates]
  F -- no --> H[Network latency or stalled consumer - check redeliver and ack rates]

Common causes

Cause	What it looks like	First thing to check
Slow consumer processing (downstream dependency)	`messages_unacknowledged` pinned near prefetch x consumers, ack rate far below deliver rate	Consumer-side processing latency and its downstream dependencies (DB, API)
Prefetch too low	Low utilisation but unacked count is small, deliver rate capped well below what processing could sustain	`rabbitmqctl list_consumers` prefetch column
Network latency broker-to-consumer	Low utilisation with moderate prefetch and fast local processing; consumers in another region or behind a loaded LB	RTT between consumer hosts and the broker
Stuck or zombie consumer	Consumers > 0, ack rate at or near zero, unacked frozen at a fixed value	Consumer application logs; connection state on the broker
Poison message loop	Depth roughly stable, redeliver rate elevated, head message age climbing	Per-queue `redeliver` rate and `head_message_timestamp`
Hot single queue	One queue saturating while the node has idle CPU; utilisation low despite healthy consumers	Per-queue publish vs deliver rates

Quick checks

All commands are read-only.

# Per-queue utilisation, depth, unacked, and consumer count
curl -s -u guest:guest http://localhost:15672/api/queues | \
  jq '.[] | {name, consumer_utilisation, consumers, messages_ready, messages_unacknowledged}'

# Same data via CLI
rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers consumer_utilisation

# Prefetch and ack mode per consumer
rabbitmqctl list_consumers

# Per-queue rates: is ack keeping up with deliver?
curl -s -u guest:guest http://localhost:15672/api/queues | \
  jq '.[] | {name, publish: .message_stats.publish, deliver: .message_stats.deliver_get, ack: .message_stats.ack, redeliver: .message_stats.redeliver}'

# Head message age: how long the oldest ready message has waited
curl -s -u guest:guest http://localhost:15672/api/queues | \
  jq '.[] | {name, head_message_timestamp, messages_ready}'

# Node CPU saturation as a contributing factor
curl -s -u guest:guest http://localhost:15672/api/nodes | jq '.[] | {name, run_queue}'

Two cautions. head_message_timestamp depends on publishers setting the timestamp property; if it is 0 or absent, that check tells you nothing. And on nodes with many queues, iterating /api/queues has real overhead, so keep polling intervals at 5-10 seconds or slower.

How to diagnose it

Confirm the precondition. Check messages_ready > 0 on the queue and that the field exists (classic vs quorum). If the queue is idle, stop: there is no delivery problem, and a NaN or 1.0 reading is expected.
Compare unacked to the prefetch ceiling. Compute prefetch x active consumers and compare it to messages_unacknowledged. If unacked sits at or near that ceiling, consumers are holding all the slots the broker will give them. The constraint is processing speed (or prefetch sizing), not consumer count. This is also the dangerous state: unacked messages are pinned in memory and cannot be paged to disk, so sustained growth here is a precursor to the memory alarm.
Check the ack/deliver gap. If ack is near zero while deliver is positive, consumers receive but never finish. Look at consumer application logs and downstream dependencies. If both are near zero with consumers attached, suspect a stuck or zombie consumer: the TCP connection is open but the application is dead or deadlocked.
Check prefetch. If unacked is far below the ceiling and prefetch is 1 or 2, the ack round trip is the throttle. The broker delivers one message, waits for the ack, delivers the next. Utilisation collapses even though each individual process step is fast.
Check redeliver. An elevated per-queue redeliver rate with stable depth points at a poison message: the head message is delivered, nacked, requeued, delivered again. Other messages wait behind it. See the poison message guide linked below.
Check network RTT. If prefetch and processing both look fine, measure latency from consumer hosts to the broker. Cross-region consumers or a congested load balancer stretch every delivery cycle.
Check for a hot queue. A single queue is served by a single Erlang process and is effectively bound to one core. If the node has idle cores but one queue’s deliver rate has plateaued, the queue process itself may be the ceiling. Check the node run_queue for scheduler saturation as well; high run queue raises latency for everything, including delivery.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
`consumer_utilisation` per queue	Direct measure of delivery-side effectiveness	< 0.5 sustained with `messages_ready > 0`
`messages_unacknowledged` vs prefetch x consumers	Tells you whether consumers hold all available slots	Ratio near 1.0 and not draining
Per-queue ack vs deliver rate	Divergence means consumers receive but do not finish	ack < 50% of deliver for > 5 minutes
Per-queue `redeliver` rate	Poison message or repeated consumer failure	Sustained non-zero on one queue
`head_message_timestamp`	Latency the depth number hides	Head age growing past the queue’s SLA
Node `run_queue`	Scheduler saturation slows all delivery	Sustained above core count
Global `mem_used / mem_limit`	Unacked growth eventually triggers the memory alarm	Ratio > 0.7 sustained

Fixes

Slow processing

Fix the consumer’s downstream dependency or the processing path itself. This is the most common root cause and no broker-side tuning compensates for it. Adding consumers helps only if the queue has enough ready messages to keep them fed and processing is parallel-safe. If unacked is already at the prefetch ceiling, more consumers do help because they add slots; if depth is small, they do not.

Tradeoff: horizontal consumer scale-out assumes messages are independent. If ordering matters, use single active consumer semantics and fix the processing speed instead.

Prefetch too low

Raise prefetch in the consumer client. The right value balances delivery continuity against memory and fairness: prefetch counts messages held per consumer as unacked, and unacked messages are pinned in broker memory. RabbitMQ’s benchmarking showed utilisation climbing from ~14% at prefetch 1 to ~70% at prefetch 30 over localhost, with returns flattening beyond that as network bandwidth became the limit. Start in the tens, not the thousands, and watch messages_unacknowledged after the change.

Tradeoff: high prefetch lets one consumer hoard messages while peers idle, and a consumer crash requeues its entire unacked set in one burst.

Network latency

Move consumers closer to the broker, or raise prefetch to overlap the round trips. Prefetch is the cheaper mitigation: a larger in-flight window hides RTT the same way TCP window scaling does.

Stuck or zombie consumers

Close the dead connections via the management API so their unacked messages requeue and live consumers take over. Fix the application so it acks or nacks deterministically, and consider the consumer delivery timeout (default 30 minutes; configurable per queue since RabbitMQ 3.12) as a backstop for consumers that never ack.

Hot single queue

Shard the work across multiple queues, for example with a consistent hash exchange, so delivery work spreads across cores. A single queue cannot scale past one scheduler.

Prevention

Alert on the right condition. consumer_utilisation < 0.5 sustained for 10+ minutes AND messages_ready > 0. Alerting on utilisation alone pages you for idle queues.
Track unacked against the prefetch ceiling, not just queue depth. Unacked pinned at the ceiling for minutes is the earliest warning of both delivery stall and memory risk.
Set prefetch deliberately in client configuration and document the expected value per consumer group so list_consumers output is auditable.
Monitor per-queue redeliver and head age so poison messages are caught before they masquerade as a capacity problem.
Load-test with realistic consumer RTT before placing consumers in a different region from the broker.

How Netdata helps

Per-queue utilisation alongside depth and unacked in one view, so the “consumers attached but not keeping up” pattern is visible without joining API responses by hand.
Ack vs deliver rate correlation per queue, which separates “receiving but not finishing” (processing problem) from “not receiving” (prefetch or latency problem) in seconds.
Redeliver rate per queue to rule poison messages in or out before you start tuning prefetch.
Unacked vs ready trends, surfacing the memory-risk case where unacked growth precedes the memory alarm.
Node-level run queue and memory ratio on the same dashboard, so you can tell a broker-side saturation problem from a consumer-side one without switching tools.