Skip to article
Integration Messaging

Dead-letter queue

A dead-letter queue stores messages that could not be delivered or processed successfully.

Source: Microsoft Learn - Azure integration services documentation Reviewed 2026-05-03

Category
Integration
Difficulty
fundamentals
CLI mappings
11
Learning route
Reference → diagnostic → practice
Exam trap
Using the term without confirming the resource scope, region, and subscription context.
Production check
Can you identify the subscription and resource group that own Dead-letter queue?
Exam bridge

Turn this definition into exam evidence.

This guide explains the concept and its production context. Use the diagnostic to see whether the topic is actually weak, then move into targeted practice without treating this page as an official objective mapping.

Start a free diagnostic Choose an exam Practice this topic
Practice this topic Microsoft Learn
Article details and learning context
Aliases
DLQ
Difficulty
fundamentals
CLI mappings
11
Last verified
2026-05-03
Related context fundamentals premium
Compare related concepts Search related resources Browse the glossary

Understand the concept

Why it matters

Dead-letter queue matters because integration and messaging decisions become production behavior: cost, security, reliability, performance, and supportability all depend on whether the team understands the resource, setting, or pattern before changing it.

Technical context

In Azure, Dead-letter queue belongs to the Messaging area and usually shows up when a workload crosses resource configuration, identity, networking, data, or operations boundaries. The mapped CLI commands, especially commands near az servicebus topic, help turn the term from a definition into something you can inventory, verify, automate, or troubleshoot.

Exam context

Compare with

Service Bus queue Service Bus

Where it is used

Where you see it

  1. Messaging
  2. Service Bus namespace
  3. Event Hubs namespace
  4. Event Grid topic
  5. Logic App designer

Common situations

  • Move events or messages between applications without direct synchronous dependencies.
  • Build workflows that coordinate systems, APIs, data, and human approvals.
  • Troubleshoot dead-letter, retry, ordering, throughput, or subscription behavior.
  • Document how producers and consumers interact in a production system.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Using Dead-letter queue in Azure operations

An Azure operator can use Dead-letter queue to plan, inspect, automate, or troubleshoot a workload without losing sight of subscription, resource group, identity, and monitoring context.

Azure CLI

Use Azure CLI for Dead-letter queue when you need repeatable evidence or automation instead of a one-off portal check. Commands near az servicebus topic let you inspect current state, script environment setup, compare dev/test/prod, and document exactly what changed.

Useful for

  • Inspect namespaces, topics, queues, subscriptions, rules, and endpoints during incidents.
  • Automate environment creation for messaging or workflow infrastructure.
  • Check network, identity, diagnostic, and throughput settings before rollout.
  • Capture state before changing message routing or workflow behavior.

Before you run a command

  • Run az account show and confirm the tenant, subscription, and user or service principal context.
  • Confirm the resource group, resource name, and region match the environment you intend to inspect or change.
  • Prefer read-only discovery commands first; only run mutating, cost-impacting, security-impacting, or destructive commands after review.
  • Copy command output into a change record or incident notes when the command is used for production evidence.

What the output tells you

  • Whether Dead-letter queue exists at the expected Azure scope and under the expected resource owner.
  • Which location, SKU, identity, network, state, or relationship fields are currently configured.
  • Whether the command is showing a resource problem, an access problem, a naming/scope problem, or a missing dependency.
  • What safe follow-up command or related term should be checked next.

Mapped commands

Adjacent discovery commands

adjacent 
az resource list --resource-group <resource-group> --output table
az resource
read-only Microsoft Learn 
az resource show --ids <resource-id>
az resource
read-only Microsoft Learn

Servicebus operations

direct 
az servicebus namespace list --resource-group <resource-group>
az servicebus
read-only Microsoft Learn 
az servicebus namespace show --name <namespace> --resource-group <resource-group>
az servicebus
read-only Microsoft Learn 
az servicebus namespace create --name <namespace> --resource-group <resource-group> --location <region> --sku Standard
az servicebus
cost-impacting Microsoft Learn 
az servicebus queue list --namespace-name <namespace> --resource-group <resource-group>
az servicebus
read-only Microsoft Learn 
az servicebus queue create --name <queue> --namespace-name <namespace> --resource-group <resource-group>
az servicebus
cost-impacting Microsoft Learn 
az servicebus topic list --namespace-name <namespace> --resource-group <resource-group>
az servicebus
read-only Microsoft Learn 
az servicebus topic create --name <topic> --namespace-name <namespace> --resource-group <resource-group>
az servicebus
cost-impacting Microsoft Learn 
az servicebus topic subscription list --topic-name <topic> --namespace-name <namespace> --resource-group <resource-group>
az servicebus
read-only Microsoft Learn 
az servicebus topic subscription create --name <subscription> --topic-name <topic> --namespace-name <namespace> --resource-group <resource-group>
az servicebus
cost-impacting Microsoft Learn

Architecture context

A dead-letter queue sits in the failure-handling lane of a message-driven design, not as an afterthought bolted onto the consumer. In Service Bus, Storage Queue patterns, Event Grid delivery, or Functions-triggered processors, it gives operators a durable place to isolate messages that exceeded delivery attempts, expired, failed validation, or could not be routed safely. Architects usually pair it with retry policy, poison-message handling, correlation identifiers, and replay runbooks. The important boundary is ownership: the producer, broker, and consumer must agree what gets dead-lettered, who reviews it, and when replay is allowed. Good designs expose dead-letter depth through Azure Monitor, keep payloads protected, and treat cleanup as controlled remediation, not a blind purge.

Security
Use managed identity, private endpoints, scoped access policies, and careful token handling.
Cost
Watch throughput units, operations, retained events, workflows, and API gateway capacity.
Reliability
Design retries, dead-letter handling, ordering, idempotency, and back-pressure explicitly.
Performance
Tune partitioning, batching, concurrency, and workflow trigger behavior.
Operations
Message and workflow systems need clear observability and replay/debug procedures.

Common mistakes

  • Using the term without confirming the resource scope, region, and subscription context.
  • Copying a command into production without checking identity, cost, and deletion impact.
  • Treating Dead-letter queue as just a label instead of checking the Azure scope, owner, and resource that it affects.
  • Running a mutating or destructive CLI command before confirming the active subscription, resource group, and target name.