# The outage lasted 18 minutes. Your retries lasted 4 seconds.

> 720 good orders in the dead-letter queue, and not one of them was poison.

- **Format:** short video, 12 steps, ~50 seconds
- **Topic:** Why an 18-minute dependency outage dead-letters every message in the queue — MaxDeliveryCount is an attempt count, not a retry window, and Service Bus has no backoff between redeliveries.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Tags:** azure, azureservicebus, servicebus, deadletterqueue, poisonmessage, azurefunctions, retrypattern, resilience, systemdesign, microsoftazure, cloudarchitecture, dotnet, az305, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/azure-poison-message-retry-window/

---
## What you'll learn

- Why ten redeliveries take about four seconds, not four minutes
- That MaxDeliveryCount caps attempts and says nothing at all about time
- How to build the backoff Service Bus does not give you, with ScheduledEnqueueTimeUtc

## Understand it one step at a time

### 1. 40 orders a minute, all fine

A queue, a worker, and a downstream API. Every setting on this queue is the Azure default.

### 2. 11:03 — the inventory API starts failing

Not down. Worse: up, fast, and returning 503 to everything. It will do this for eighteen minutes.

### 3. One order. Ten attempts. Four seconds

Order 41883 arrives, fails ten times, and is dead-lettered before you could refresh a dashboard.

### 4. Nothing waited between the attempts

An abandoned message is redelivered at once. Service Bus has no backoff, and never claimed to.

### 5. The outage had 17 more minutes to run

The message needed to survive eighteen minutes. It was built to survive four seconds.

### 6. 720 orders in the dead-letter queue

Forty a minute for eighteen minutes. The queue did not back up — it emptied itself into the DLQ.

### 7. Not one of them was poison

Every message in there is valid. Replay them now, with the API back, and all 720 succeed.

### 8. MaxDeliveryCount is not a retry policy

It caps how many times one bad message can hurt you. It says nothing about how long you try.

### 9. Retry on a schedule, not in a loop

Complete the message and re-enqueue a copy for later. Now your attempts span the outage instead of the first second of it.

### 10. Raising it to 100 changes nothing

A hundred attempts with no gap is forty-one seconds. You bought 37 more seconds of an 18-minute outage.

### 11. Dead-letter the real poison on attempt one

A message that can never succeed should not get ten tries. Your handler knows the difference; the broker does not.

### 12. Ten tries is not ten chances

The count is yours to set. The interval was never on offer — you have to build it.

---

## The takeaway

**A retry count is not a retry window**

Service Bus gives you the attempts. The time between them is the part you have to build.