How many times a queue can deliver the same message
Your queue promises at-least-once delivery and you need to know the upper bound before designing around it.
There is no upper bound from the guarantee itself — at-least-once places no ceiling on repetition. The practical limit is the maximum receive count, after which the message goes to a dead letter queue, and that is typically set between three and five. Until that threshold, redelivery continues every time a consumer fails to acknowledge in time.
What triggers a redelivery
A message is redelivered whenever it is not acknowledged within the visibility timeout. That includes a crashed consumer, but also one that is merely slow — the broker cannot tell the difference, which is why a long job without a heartbeat is redelivered while it is still running.
Where the ceiling comes from
The ceiling is a configuration value, not a property of the guarantee. A maximum receive count of five means the sixth delivery goes to the dead letter queue instead. Without one configured, a message that always fails is redelivered indefinitely and consumes capacity forever.
The overlap case
Redelivery does not cancel the original. A slow consumer and its replacement can process the same message simultaneously, so handlers must tolerate concurrent duplicates and not merely sequential ones. This is the failure that deduplication by prior check misses.
What to do with what lands in the dead letter queue
A dead letter queue that nobody reads is a slower way of losing messages. Alert on depth rather than on individual arrivals, because one message is usually a poison payload and a sudden rise is usually a deployment. Redriving requires the same idempotency the original consumer needed, since some of those messages were partly processed before failing.
What bounds redelivery
What bounds redelivery
| Setting | Effect if too low | Effect if too high |
|---|
| Visibility timeout | Redelivery while still processing | Slow recovery after a crash |
| Max receive count | Transient failures dead-letter | A poison message retries forever |
| No dead letter queue | n/a | Failing message consumes capacity indefinitely |
Key facts
- At-least-once delivery places no upper bound on how many times a message may arrive; the ceiling comes from the configured maximum receive count.
- A maximum receive count between three and five is the common setting, after which the message is routed to a dead letter queue.
- A message is redelivered whenever it is not acknowledged within the visibility timeout, which a slow consumer triggers just as a crashed one does.
- Redelivery does not cancel the original delivery, so two consumers can process the same message at the same time.
- Without a dead letter queue, a message that always fails is redelivered indefinitely and permanently consumes consumer capacity.
Frequently asked questions
Can I set the max receive count to one?
You can, and it converts every transient failure into a dead-lettered message. Since transient failures are the common case, this usually moves the problem rather than removing it.
How do I stop redelivery of a long-running job?
Extend the visibility timeout beyond the worst-case duration, or heartbeat to extend it while working. Neither removes the need for the handler to be safe to run twice.
Is it safe to redrive a dead letter queue?
Only if the consumer is idempotent, and by the time messages are dead-lettered some of them have been partly processed several times. Redriving into a consumer that is not safe to repeat converts one failure into several.
Machine-readable copy of this page:
/guide/how-many-times-a-message-can-be-delivered.md