# The gateway timed out. Where did the payment go?

> Retries, delivery counts and the queue Azure fills for you whether you read it or not.

- **Format:** short video, 10 steps, ~32 seconds
- **Topic:** Azure Service Bus retry and dead-letter queue — what happens to a payment when the gateway times out, and where the message that can never succeed ends up.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Tags:** azure, azureservicebus, deadletterqueue, servicebus, messagequeue, systemdesign, microsoftazure, azurecloud, cloudarchitecture, dotnet, backenddeveloper, az305, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/azure-service-bus-dead-letter/

---
## What you'll learn

- Why you never complete a message you cannot confirm
- How delivery count and MaxDeliveryCount stop an endless retry
- What lands in the dead-letter queue, and what to alert on

## Understand it one step at a time

### 1. 11:42 — a customer pays

The order is on the queue. A worker picks it up and calls the payment gateway.

### 2. The gateway times out

No response in 30 seconds. Did the card get charged, or not? The worker cannot tell.

### 3. Don't complete what you can't confirm

Complete() deletes the message for good. On an unconfirmed charge, that is how a payment disappears.

### 4. It comes back automatically

You wrote no retry loop for this. The broker redelivers, and the count goes up on its own.

### 5. Attempt 3 — the gateway is back

Transient failures are the common case. Nobody was paged and nothing was lost.

### 6. But some messages never succeed

Order #90219 is missing its currency field. The handler throws on it every single time.

### 7. Ten attempts. Same failure.

Every redelivery costs a worker slot, and the result is identical. MaxDeliveryCount is the stop.

### 8. Dead-letter queue catches it

Azure moves it to payments/$DeadLetterQueue with the reason attached. Off the queue, still stored.

### 9. Skip it, and you lose the customer

The DLQ is on by default — Azure fills it for you. The mistake nobody admits is never reading it.

### 10. Failures don't vanish

Retry absorbs the blip. The dead-letter queue holds everything else — until somebody looks.

---

## The takeaway

**A queue you never read is a queue you never had**

Retries handle the outage. An alert on dead-letter depth handles everything retries cannot.