Error

NOT_FOUND - no exchange: what RabbitMQ does with a message published to an exchange that does not exist

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

NOT_FOUND - no exchange 'orders.events' in vhost 'orders'

A typo in an exchange name, an exchange deleted by someone cleaning up, or a service that publishes before the one that declares the topology has started. Here is what happens to the message, measured on RabbitMQ 4.3.6, and the quiet variant of the same mistake that gives no error at all.

What happens to the message

It is gone. The broker has nowhere to put it and closes the channel with the error above. When your code notices depends on whether it uses publisher confirms:

• Without confirms, the publish call returns normally. The error arrives asynchronously, and the next operation on the channel fails with ChannelClosedByBroker (404) NOT_FOUND - no exchange. The connection stays open, so a health check that only looks at the connection sees nothing wrong.
• With confirms, the publish call itself raises the error. Your code knows which message was lost.

The fix

• Declare the exchanges you publish to when the service starts. Declaring an existing exchange with the same type and arguments is a no-op, so every service can do it.
• Use publisher confirms for anything you cannot afford to lose, and treat a closed channel as a failed publish.
• Reopen a channel after it was closed; a closed channel does not come back.

The quiet variant: a dead-letter exchange that does not exist

A queue's x-dead-letter-exchange is not checked when the queue is declared. We declared a queue with a dead-letter exchange that did not exist, published a message and rejected it with requeue=false:

• the declaration succeeded;
• after the reject the queue was empty, the channel still open, and the broker log had no line about it.

Every message that dies in that queue is dropped. The same happens when the dead-letter exchange exists but no binding matches the dead letter's routing key. Check the dead-letter exchange of every queue once, and again after a rename.