Although im not sure if you want to go the way that @rogeralsing describes in his gist. Seems that AzureServicebus has a different idea about how to handle message failures. Not Acking a message is a valid application level error scenario. Whereas with the RMQ clients, Ack-ing (or not Ack-ing due to timeout) is an infrastructure level concern, and application level error scenario's should be handled by throwing an exception, which causes the message to go into the error queue. This is from the philosophy that if your message fails to process, its poisoned and any retries should be explicit (in this case, you republishing stuff from the error queue). Sofar iv'e seen all RMQ clients follow this philosophy, at least the .Net clients do.