Find out why messages arrived
Messages can be dead-lettered for several reasons, including rejection without requeue, expiry, queue length limits or delivery limits where applicable. Inspect the queue policy, routing, message headers and consumer logs for the installed RabbitMQ version. Treat payloads as sensitive.
Do not replay everything immediately. A malformed message, a missing dependency and an already completed business action require different handling. Check whether the target queue and dead-letter exchange are available and whether the original failure has been corrected.
Define the replay contract
Identify a stable business operation ID and how the consumer prevents or reconciles duplicate effects. Broker delivery and application completion are separate: a message can be processed successfully and then redelivered after an acknowledgement is lost.
Decide which messages are eligible, preserve the original evidence, and test a small approved batch in staging or with a controlled production procedure. Use a rate that the consumer and downstream systems can sustain. Avoid creating an endless dead-letter loop.
Reconcile the result
Compare replayed message IDs with completed business operations, failures and remaining dead letters. Confirm ordering requirements and downstream side effects such as payments or email. Keep an audit trail of who authorized the replay and which batch was processed.
RabbitMQ dead-letter delivery guarantees depend on queue type and configuration. Review the current documentation and your deployed settings instead of assuming every dead-lettered message was safely stored.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.