How to defer and retrieve Azure Service Bus messages

Updated July 21, 2026

Azure Service Bus deferral sets aside a received message that belongs in the workflow but cannot be processed yet. The deferred message remains stored in its queue or topic subscription, is skipped by normal receive operations, and must later be retrieved by its broker-assigned Sequence Number.

With QueueExplorer, select one or more active messages and choose Defer. The Deferred view then lets you find and inspect deferred messages without building a separate sequence-number registry or diagnostic program.

Deferral is not a delay timer. Azure Service Bus does not automatically make a deferred message active after five minutes or at a chosen time. Your application must retain its Sequence Number and retrieve it when the missing prerequisite is satisfied. Use scheduled delivery when a message should become active at a time.

When Azure Service Bus message deferral is useful

Deferral is designed for a specific message whose prerequisite has not arrived yet. Typical examples include:

  • a payment event arriving before the corresponding order;
  • a workflow step arriving before an earlier step for the same business item;
  • a message that needs a reference record another message will create; or
  • a rendezvous workflow that must correlate events from multiple sources.

Do not defer every delivery because a shared database, API, or dependency is unavailable. Microsoft recommends suspending receiving in that situation. Deferring a large outage backlog creates a second inventory of Sequence Numbers that must be tracked and retrieved individually.

1. Find and defer selected messages

  1. Open the active queue or topic subscription in QueueExplorer.
  2. Load a small practical batch and filter by body, IDs, Session ID, or application properties.
  3. Inspect the selected messages and record their current Sequence Numbers.
  4. Right-click the selection and choose Defer.
  5. Refresh the active and Deferred views, then record the final deferred Sequence Numbers in the incident or workflow record.
Defer command for selected Azure Service Bus messages in QueueExplorer
Defer only messages whose processing prerequisite is temporarily missing

Deferral is a settlement action on a Peek-Lock delivery. A message returned only by Peek has no lock token and cannot itself be deferred. When QueueExplorer must reach a selected message deeper in an active queue, earlier deliveries may be received and abandoned; their Delivery Count can increase.

Download QueueExplorer

Free trial for Windows, macOS, and Linux

2. Browse deferred Azure Service Bus messages

  1. Expand the queue or subscription in QueueExplorer to display its message-state views.
  2. Select Deferred.
  3. Add Sequence Number, Message ID, Correlation ID, Session ID, Enqueued Time, Expires At, and application properties as columns.
  4. Filter the loaded rows and inspect message bodies without retrieving them for processing.
Deferred Azure Service Bus messages view in QueueExplorer
QueueExplorer presents deferred messages as a dedicated view under the entity

Deferred messages do not actually live in a separate broker subqueue like dead-letter messages. They remain in the main queue or subscription with deferred state. Azure Service Bus Peek includes them, and the Sequence Number is the key required by a receive-deferred API.

If an application loses its sequence-number registry, use browsing to rediscover candidates. This is a recovery technique, not a substitute for persisting the Sequence Number transactionally with the business workflow.

3. Retrieve, replay, move, or delete deferred messages

Once the prerequisite exists, choose the outcome deliberately:

  • Process the deferred delivery: application code receives it by Sequence Number under a lock, performs the work, and completes it only after success.
  • Return it to normal delivery: QueueExplorer can move it back to the original entity. This sends a new active message and settles the deferred original, so the new message has a new Sequence Number and Enqueued Time.
  • Move or copy it elsewhere: send it to a quarantine, repair, or test queue, then verify the destination before removing the original.
  • Delete it: permanently settle an obsolete deferred message after preserving diagnostic evidence if needed.

For time-based retry, Microsoft describes persisting the deferred Sequence Number and scheduling a lightweight reminder message. When the reminder becomes active, the consumer retrieves the original by that number. This keeps the original deferred instead of repeatedly abandoning and redelivering it.

Deferred messages, TTL, expiration, and dead-lettering

Deferred messages have an important expiration edge case. Microsoft documents that an expired deferred message is not automatically moved to the dead-letter queue merely because its TTL elapsed. The service evaluates that condition when a client attempts to retrieve the deferred message by Sequence Number.

If it is expired at retrieval time and dead-letter-on-expiration is enabled for the entity, Azure Service Bus moves it to the dead-letter queue. A diagnostic Peek may still show an expired message before asynchronous cleanup or state transition. Monitor deferred inventory explicitly; normal active-message counts do not tell the whole story.

See Microsoft's current message deferral documentation for the broker behavior.

Defer, abandon, schedule, or dead-letter?

Action What happens Use when
AbandonReturns the delivery to normal availability and increments Delivery CountA short transient retry is appropriate
DeferSets the message aside until retrieved by Sequence NumberThis specific message awaits a prerequisite
ScheduleCreates a message that becomes active at a chosen future timeAvailability should be time-based
Dead-letterMoves the delivery to the DLQ with diagnostic propertiesNormal processing should stop pending diagnosis or repair
CompleteRemoves the delivery as successfully processedThe work and required side effects succeeded

Production deferral checklist

  • Persist each Sequence Number with the workflow record before the lock is settled as deferred.
  • Define who or what will retrieve it and which event or timer triggers that action.
  • Monitor the age and count of deferred messages instead of letting them become invisible backlog.
  • Account for TTL and dead-letter-on-expiration behavior.
  • Pause competing consumers during manual changes when the exact selection matters.
  • Back up important messages before replay, move, or deletion.
  • Make downstream processing idempotent because a replay creates a new active delivery.

Frequently asked questions

Where are deferred Azure Service Bus messages stored?

They remain in the main queue or subscription with deferred state. QueueExplorer displays a convenient Deferred view, but Azure Service Bus does not store them in a separate deferred subqueue.

How do I retrieve a deferred Azure Service Bus message?

Use its broker-assigned Sequence Number with a receive-deferred API, then settle the locked delivery after processing. QueueExplorer can browse and operate on deferred messages without custom diagnostic code.

Does a deferred message become active automatically?

No. Deferral has no wake-up time. A client must retrieve it by Sequence Number, or an operator can replay it as a new active message.

Can I defer a message from a topic?

Messages are received and deferred from a topic subscription, not from the publishing topic itself. The deferred copy belongs to that subscription.

For a time-based alternative, see how to schedule Azure Service Bus messages.

QueueExplorer: a better way to inspect and manage Azure Service Bus

QueueExplorer showing Azure Service Bus messages

See what is happening in Azure Service Bus and resolve message problems without writing one-off tools. Browse queues and topic subscriptions, inspect message contents, and manage your Azure Service Bus environment from one desktop application. Try it free on Windows, macOS, or Linux.

Download QueueExplorer     Learn more