RabbitMQ Publisher Confirms: Guarantee Message Durability (2026)

RabbitMQ publisher confirms don’t actually guarantee message durability; they guarantee delivery to the broker.

Let’s see it in action. Imagine you have a producer sending messages to a RabbitMQ exchange. Normally, once the producer sends a message, it assumes it’s gone and RabbitMQ has it. But what if the network glitches right after the producer sends it, or RabbitMQ crashes before it’s fully written to disk? The producer wouldn’t know. Publisher confirms solve this by creating a feedback loop.

Here’s a basic setup in Python using pika:

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

# Enable publisher confirms
channel.confirm_delivery()

message_body = b"Hello, RabbitMQ!"
properties = pika.BasicProperties(delivery_mode=2) # Make message persistent

try:
    channel.basic_publish(
        exchange='',
        routing_key='my_queue',
        body=message_body,
        properties=properties
    )
    print("Message sent. Waiting for confirm...")
    # This call blocks until a confirm is received or a timeout occurs
    # The return value is True if confirmed, False otherwise
    if channel.wait_for_confirms(timeout=5):
        print("Message confirmed by RabbitMQ!")
    else:
        print("Message not confirmed (timeout or NACK).")
except pika.exceptions.ChannelClosedByBroker as e:
    print(f"Channel closed by broker: {e}")
except pika.exceptions.AMQPConnectionError as e:
    print(f"Connection error: {e}")
finally:
    connection.close()

The channel.confirm_delivery() call puts the channel into confirm mode. When basic_publish is called, RabbitMQ will asynchronously acknowledge receipt of the message. The channel.wait_for_confirms(timeout=5) method is where the producer blocks and waits for this acknowledgment. If it receives an ack (acknowledgment) from RabbitMQ within the timeout, it returns True. If it receives a nack (negative acknowledgment) or the timeout expires, it returns False.

The problem publisher confirms solve is ensuring that RabbitMQ received the message from the producer and accepted it into its internal queues. This is crucial for preventing message loss due to network issues between the producer and the broker, or temporary broker unresponsiveness. It’s a signal that the message has made it into the RabbitMQ system.

Internally, when publisher confirms are enabled, RabbitMQ doesn’t immediately return OK to the producer after receiving a message. Instead, it queues up the message and only sends an ack back to the producer once it has processed the message in a way that satisfies the broker’s configuration. For persistent messages (delivery_mode=2), this means the message has been written to disk. For non-persistent messages, it means the message is safely in memory queues.

There are two main modes for publisher confirms:

1. Asynchronous: The producer sends messages without waiting for confirmation for each one. It registers a callback for ack or nack events. This is more performant.
2. Synchronous: The producer sends a message and then explicitly waits for confirmation for that specific message (like in the pika example above with wait_for_confirms). This is simpler to implement but less performant as it blocks the producer.

The key levers you control are:

• Enabling confirms: channel.confirm_delivery() on the producer side.
• Waiting for confirms: channel.wait_for_confirms() or using callbacks on the producer side.
• Message persistence: Setting delivery_mode=2 on the BasicProperties ensures that even if RabbitMQ crashes and restarts, persistent messages are reloaded from disk. Publisher confirms combined with message persistence provide the strongest guarantee against loss.

What most people don’t realize is that publisher confirms are per-channel. If you open multiple channels on the same connection, you need to enable confirms on each channel independently if you want confirmation for messages sent on those channels. A confirmation on one channel doesn’t imply anything about messages sent on another.

The next thing you’ll likely run into is handling nacks and timeouts gracefully, which often involves implementing retry mechanisms on the producer side.