RabbitMQ publisher confirms: proving the broker actually accepted your message

By default, AMQP publishing is fire-and-forget. Your client writes a message to the socket, the write succeeds, and the application moves on. That TCP write proves exactly one thing: the bytes left your process. It says nothing about whether the broker routed the message, persisted it, or even finished reading it before the connection dropped.

Publisher confirms close this gap. When enabled, the broker sends an explicit acknowledgement for every published message, after it has taken responsibility for it. Combined with the mandatory flag, confirms are the only way to get end-to-end proof that a message was both accepted and routed. Without them, entire classes of message loss are invisible: unroutable messages are silently discarded, in-flight messages vanish on connection failure, and the first symptom is a downstream consumer reporting missing data hours later.

What it is and why it matters

Publisher confirms are a RabbitMQ extension to AMQP 0-9-1. A publisher puts a channel into confirm mode by sending confirm.select; the broker replies with confirm.select-ok. From that point on, every message published on the channel gets a monotonically increasing sequence number (starting at 1), and the broker asynchronously sends back basic.ack or basic.nack referencing those sequence numbers.

Two properties make this matter operationally:

1. The ack means the broker has taken responsibility. For a routable message, the ack is sent once the message has been accepted by all queues it was routed to. For persistent messages on durable queues, that means written to disk. For quorum queues, it means a quorum of replicas has accepted it. This is a durability boundary, not just a “we received bytes” boundary.

2. It is the one signal you cannot get any other way. Broker-side metrics show aggregate rates and queue depth. They cannot tell publisher instance number 7 that the specific message it sent at 03:14:22 was lost when a connection flap killed the socket mid-publish. Only the client knows which sequence numbers never got confirmed.

A channel in confirm mode cannot be made transactional, and a transactional channel cannot be put into confirm mode. Confirms are the modern, dramatically cheaper replacement for AMQP transactions.

How it works

The interaction order matters, because the most common operator surprise lives here:

sequenceDiagram
    participant P as Publisher
    participant B as Broker
    P->>B: confirm.select
    B-->>P: confirm.select-ok
    P->>B: basic.publish (seq 1, mandatory=true)
    P->>B: basic.publish (seq 2)
    alt routable message
        B-->>P: basic.ack (seq 2) - accepted by all queues, persisted
    end
    alt unroutable message
        B-->>P: basic.return (seq 1) - no queue matched
        B-->>P: basic.ack (seq 1)
    end
    alt internal queue process error
        B-->>P: basic.nack - exceptional, requeue field ignored
    end

Read the unroutable branch carefully, because it is the number-one misconception about this feature:

An ack does not mean the message reached a queue. When a message cannot be routed to any queue, the broker still sends a confirm (an ack) once the exchange has verified there is no matching binding. The ack means “the broker accepted responsibility for this message,” and for an unroutable message, the broker’s responsibility ends at the exchange. If you want to know the message went nowhere, you must publish with mandatory=true and handle basic.return, which the broker sends before the ack for unroutable mandatory messages. Confirms prove acceptance; mandatory plus returns prove routing. You need both.

Without mandatory=true, an unroutable message is silently discarded at the exchange. It appears in no queue, no error log, and no per-queue counter. The only broker-side trace is the global return_unroutable counter in message_stats, and that only increments for mandatory messages. This is the silent routing loss pattern: publish rate is healthy, queue depth is flat, deliver rate is zero, and everything looks green.

A nack is rare. The broker sends basic.nack only in exceptional cases, when the Erlang process responsible for a queue fails internally. The requeue field is ignored for publisher nacks. If you see nacks at any meaningful rate, something is wrong at the broker level, not with your routing.

Acks can be slow by design. For persistent messages, the message store persists in batches to amortize fsync calls. Under sustained load, confirm latency of a few hundred milliseconds is normal and expected. It is not a bug and not, by itself, a reason to change anything.

The three client strategies

There are three documented ways to consume confirms, and they differ by orders of magnitude in throughput:

• Streaming (asynchronous) confirms. Publish continuously and handle acks and nacks in a callback, tracking outstanding sequence numbers. This is the recommended strategy. The client keeps a map of unconfirmed messages, removes them as acks arrive (acks may be cumulative, with the multiple flag), and re-publishes or alerts on nacks and on entries that age past a timeout.
• Batch publishing. Publish a batch of messages, then wait for confirms for the whole batch before sending the next one. Simpler to reason about, and failures are scoped to a known batch, but the pipeline stalls at each batch boundary.
• Publish and wait. Publish one message, block until its confirm arrives, then publish the next. This serializes the publish path and collapses throughput, since every message pays at least a network round trip plus persistence latency. Treat it as an anti-pattern outside of tests and very low-rate, high-value messages where the per-message proof justifies the cost.

Two practical notes on timeouts. First, RabbitMQ has no server-side confirm timeout. The timeout is entirely a client-side construct (for example, waitForConfirmsOrDie(timeout) in the Java client). If you choose a timeout shorter than the broker’s persistence batching under load, you will re-publish messages the broker had already accepted. Second, when a resource alarm is active, publishing connections are blocked and confirms cannot be delivered until the alarm clears. A confirm timeout that fires during a memory or disk alarm is telling you the broker is in a known emergency state, not that your messages were lost. Size client timeouts to outlast the alarm durations you consider plausible, and correlate timeout events with broker alarm state before treating them as loss.

Where it shows up in production

Reconnect and retransmission. If a connection drops with unconfirmed messages outstanding, you cannot know which of them the broker processed. The confirmations may have been lost in flight. The correct behavior is to retransmit the unconfirmed set on reconnect, which gives you at-least-once semantics. Consumers downstream must be idempotent or deduplicate, because duplicates are a designed-in consequence of doing confirms correctly. Client libraries with automatic recovery (Java, .NET, Bunny) restore confirm mode on the recovered channel, but the unconfirmed-message bookkeeping across the reconnect is still your application’s job.

Confirm latency as an early warning. The time between publish and ack is one of the few signals that degrades before the broker starts visibly throttling you. Rising confirm latency reflects pressure in the write path: persistence batching getting slower under disk I/O contention, queue processes falling behind, or credit-based flow control beginning to engage. Instrument this at the client and alert on the trend, because it gives you roughly 5-10 minutes of lead time before connections start showing flow state or a resource alarm blocks publishers entirely. There is no broker-side metric for this. The broker cannot know what the latency looked like from your side of the socket; you must measure it in the publisher and export it yourself.

Alarms freeze the confirm stream. During a memory or disk alarm, all publishing connections cluster-wide are blocked. Your publisher sees confirms stop arriving and writes eventually time out or fail with an I/O error. The broker-side tells are connections in blocked or blocking state and the mem_alarm / disk_free_alarm booleans. If your publisher alerts fire whenever confirms stall, you will get paged twice for every disk alarm: once by the broker monitoring and once by every publisher. Deduplicate by correlating client-side confirm stalls with broker alarm state.

The aggregate confirm rate. The broker exposes a confirm counter in message_stats (via GET /api/overview). The confirm rate tracks the publish rate in a healthy system. A publish rate that stays high while the confirm rate sags means the write path is backing up, which is the broker-side view of the same early warning.

Tradeoffs and common misuses

• Confirms without mandatory. You get proof of acceptance but not of routing. Unroutable messages are acked and gone. If the point of enabling confirms was “prove messages aren’t lost,” you have only half the proof. Set mandatory=true and handle basic.return everywhere it matters.
• Synchronous confirms on the hot path. Wrapping every publish in a blocking wait destroys throughput and then gets blamed on RabbitMQ. Use streaming confirms; use batch waits if you must simplify; never wait per message at volume.
• Treating a nack as a routing failure. Nacks mean internal broker faults. Routing failures come back as basic.return plus an ack. Alerting on nacks as “message rejected” misdirects the incident response.
• Assuming exactly-once. Confirms give you at-least-once. Any design that retransmits unconfirmed messages on reconnect will produce duplicates. If consumers are not idempotent, the failure mode you get is duplicated side effects, which is harder to debug than a gap.
• Confirms as a substitute for consumer acknowledgements. Publisher confirms cover the publisher-to-broker leg. The broker-to-consumer leg has its own acknowledgement protocol, and unacked message accumulation on the consumer side is a separate failure mode with its own signals. Proving the broker accepted the message says nothing about whether a consumer ever processed it.

Signals to watch in production

How Netdata helps

• Netdata’s RabbitMQ collector pulls the message_stats counters from the management API, so you can chart the confirm rate against the publish rate and see the write path backing up before any alarm fires.
• The return_unroutable counter is collected alongside the other message rates, making the mandatory-return half of the routing proof visible without log scraping.
• Netdata surfaces the mem_alarm and disk_free_alarm booleans per node, which lets you overlay alarm windows on client-reported confirm latency spikes and distinguish “broker emergency” from “publisher problem” at a glance.
• Because Netdata also collects queue totals (ready and unacknowledged) and publish/deliver/ack rates on the same per-second timeline, the silent-loss composite (publish up, deliver zero, depth flat) is a single-dashboard correlation rather than three separate queries.
• Pairing broker-side signals with the confirm latency you export from your publishers closes the loop: the client metric gives you the early warning, and Netdata gives you the broker-side explanation for it.

Related guides

• RabbitMQ connection blocked / blocking: publishers frozen by a resource alarm
• RabbitMQ connection in flow state: credit-based backpressure explained
• RabbitMQ disk free limit alarm: free disk space insufficient and publishing halted
• RabbitMQ disk_free_limit at the default 50MB: the production footgun
• RabbitMQ consumers connected but not acknowledging: the consumer black hole
• RabbitMQ channel leak and churn: the channel-per-message anti-pattern
• RabbitMQ connection storm: reconnect loops, FD pressure, and CPU spent on handshakes