Options for message Time to Live for DLQ

Peter Rabasa 0 Reputation points
2026-06-22T21:37:19.7433333+00:00

Is it possible to enable or to have the same TTL handling options as Active Messages for messages in the Dead Letter Queue.

Azure Service Bus
Azure Service Bus

An Azure service that provides cloud messaging as a service and hybrid integration.

4 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-06-22T21:37:37.56+00:00

    No. Dead-letter queues in Azure Service Bus do not support time-to-live (TTL) handling in the same way as active messages.

    Key behaviors from the documentation:

    1. Active messages (main queue/topic/subscription)
      • Messages have a TTL that can be set per message or at the entity (queue/topic) level.
      • When TTL expires, messages can optionally be moved to the dead-letter queue if automatic dead-lettering on expiration is enabled. Otherwise, they are dropped.
      • Entity-level TTL acts as a default and a ceiling for per-message TTL.
    2. Messages in the dead-letter queue (DLQ)
      • The DLQ is a subqueue of each queue or subscription and is not managed independently.
      • Time-to-live is not observed for messages in the DLQ. Messages remain there until explicitly retrieved and completed/removed.
      • There is no automatic cleanup or expiration of DLQ messages, and messages cannot be dead-lettered again from the DLQ.

    Because TTL is explicitly not applied in the DLQ and there is no automatic cleanup, the same TTL handling options that apply to active messages cannot be enabled for DLQ messages. Any lifecycle management of DLQ messages (including pseudo-TTL behavior) must be implemented by custom application logic that reads and processes/removes messages from the DLQ.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. kagiyama yutaka 5,410 Reputation points
    2026-06-23T03:10:14.4+00:00

    I think Service Bus does not apply TTL in the dead‑letter subqueue, and TTL is only checked on the main queue or subscription before a message is moved. A message in the DLQ stays there until you read and remove it.

    Was this answer helpful?

    0 comments
  3. Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator
    2026-06-23T03:27:20.6533333+00:00

    Hi @Peter Rabasa

    Thank you for reaching out to Microsoft Q&A

    Azure Service Bus Dead-Letter Queues (DLQs) do not support Time-To-Live (TTL) handling in the same way as active messages. While messages in the primary queue or topic can have a TTL configured and can expire automatically, TTL is not evaluated once a message has been moved to the DLQ. The DLQ is designed as a holding area for messages that could not be delivered or processed successfully, allowing administrators or applications to inspect and take corrective action on those messages. As a result, messages stored in the DLQ remain there indefinitely until they are explicitly retrieved and removed. Currently, Azure Service Bus does not provide a built-in option to enable automatic expiration, retention policies, or TTL-based cleanup for messages in the Dead-Letter Queue.

    Refer below points to resolve this issue or use the available workaround:

    1. Understand the DLQ Behavior

    TTL is supported only for active messages in queues, topics, and subscriptions.

    Once a message is dead-lettered, TTL is no longer observed.

    Messages in the DLQ do not expire automatically and are not removed by the Service Bus platform.

    2. Implement Custom DLQ Cleanup Logic

    Create a scheduled process (Azure Function, Logic App, WebJob, or application service) that periodically reads messages from the DLQ.

    Check the message age using properties such as EnqueuedTimeUtc.

    Remove messages that exceed your desired retention period.

    Optionally archive the messages before deletion for auditing or troubleshooting purposes.

    3. Monitor and Manage the DLQ Regularly

    Configure Azure Monitor alerts for DLQ message counts.

    Review dead-lettered messages periodically to identify application failures or processing issues.

    Resubmit valid messages after correcting the root cause.

    Remove obsolete messages manually or through automation to prevent DLQ growth over time.

    4. Consider Alternative Retention Strategies

    If long-term retention is not required, move DLQ messages to external storage such as Azure Blob Storage, Azure SQL Database, or Cosmos DB.

    Implement a separate retention policy on the archived data based on business requirements.user's question.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  4. Alex Burlachenko 25,285 Reputation points MVP Volunteer Moderator
    2026-06-25T12:43:59.9333333+00:00

    hi Peter Rabasa & thx for sharing urs issue here at Q&A portal,

    No, DLQ messages don’t get the same TTL handling as active messages. In Service Bus, when a message is moved to the dead-letter queue, it stays there until u explicitly receive/delete it, resubmit it, or purge/cleanup it yourself. TTL doesn’t keep expiring the same way after it lands in DLQ.

    So if u need DLQ cleanup, the usual pattern is a scheduled job/function that reads from the DLQ, checks EnqueuedTimeUtc or custom properties, and deletes or archives messages older than ur retention window.

    no built-in DLQ TTL policy like active queue messages. U need app-side cleanup or an ops process.

    rgds,

    Alex

    &

    If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

    and at my blog https://ctrlaltdel.blog/

     

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.