Did you know that repeatedly retrying a failed AI-agent task can make an outage worse instead of fixing it? A queue may keep delivering the same instruction after a worker crashes, a provider rejects its payload or an approval expires. A dead-letter queue, often shortened to DLQ, keeps messages that cannot be processed normally so the service can diagnose the problem without making the whole workflow spin indefinitely. It does not automatically repair the task, cancel a real-world side effect or make replay safe.
A trustworthy workflow distinguishes a temporary failure from a malformed event, a legitimate permission denial and an uncertain operation that might already have completed. It records the original event and business identities, bounds attempts, diagnoses the actual dead-letter reason, repairs the underlying problem and validates current authority before any redrive. This chapter uses an invented 120-task message ledger, an additional forty-case school-publishing transfer and provider-specific differences from AWS SQS and Azure Service Bus. None of the figures describes real eduKate operations or proves artificial superintelligence exists.
Continue the How Super Intelligence Works curriculum. The Transactional Outbox guide explains reliably recording an event intention, while Agent Cancellation explains stopping effects. Here the focus is a message that repeatedly failed: why it is isolated, who decides its next disposition and how to prevent an unsafe second effect.
Choose a useful reading route
- Trying to clear a failed queue? Begin with provider reasons, stable event identity and current authorization.
- Building a consumer? Study idempotency, ordered events and unknown external effects before implementing redrive.
- Learning Mathematics? Check the 120-event snapshot, nine-event repair and forty-task transfer.
- Protecting families? Read privacy-aware DLQ access and why approval expiry can block old messages.
Contents
- 1. A dead-letter queue is a diagnostic state, not a trash bin
- 2. Classify why the event failed before selecting a retry
- 3. AWS SQS redrive policy uses received attempts
- 4. Azure Service Bus has distinct dead-letter reasons
- 5. Delivery counts are not model-quality scores
- 6. Poison messages and transient outages need different handling
- 7. Put idempotency before consequential replay
- 8. Protect order-sensitive workflows from unsafe redrive
- 9. Authorization must survive queue delays
- 10. A fictional 120-message recovery ledger
- 11. Use a table to give each case a responsible next action
- 12. A controlled redrive exercise with conservation
- 13. Watch backlog age, not only backlog size
- 14. Safe replay starts with a source-of-truth check
- 15. Unknown effects belong in reconciliation, not a normal retry loop
- 16. Changed-context school publisher with forty tasks
- 17. Test the DLQ workflow using controlled failure injection
- 18. Privacy, retention and access of a DLQ
- 19. Implement a small but accountable recovery runbook
- Frequently asked questions
- Official provider guidance
- Related specialist reading
1. A dead-letter queue is a diagnostic state, not a trash bin
A message normally moves from an available queue into a worker’s processing attempt and then to a successful settlement or a retry. A DLQ creates a separate place for messages that cannot complete under the normal path. It makes the problem visible and keeps repeated failures from indefinitely consuming ordinary worker capacity. The underlying user request may still require a real outcome, which is why dead-lettered cannot simply mean forgotten.
Amazon SQS supports source-queue redrive policies based on maxReceiveCount, the number of receives allowed before an unconsumed message moves to the configured DLQ. Azure Service Bus has a dead-letter subqueue and records reasons such as MaxDeliveryCountExceeded or TTLExpiredException under the relevant configuration. Both systems support investigation, but their message settlement and redrive behaviour must not be treated as identical.
Consider a fictional Maths resource update. The application commits an approved notice and emits an event that should update a search index. A consumer repeatedly rejects the event because it expects a missing field. Sending it again unchanged is unlikely to help. Putting the event into a diagnosable DLQ makes it possible to repair the schema adapter and then evaluate whether a new processing attempt is still appropriate.
A DLQ is not an official source about the content of a school notice, and it cannot grant the agent permission to publish. It records an operational inability to process a message. The right user-facing status may be Pending Repair or Unresolved, rather than Completed, while a qualified owner investigates the original business task and its actual external effects.
Return to contents or continue to Classify why the event failed before selecting a retry.
2. Classify why the event failed before selecting a retry
Failures can be transient, persistent or policy-driven. A broker connection interruption may be transient; a schema mismatch or missing required field may persist for every attempt until the producer or consumer changes. A permission denial can be a correct protective outcome that must not be retried under a broader identity. An unknown provider effect needs reconciliation, not an immediate resubmit.
Define explicit categories such as retryable infrastructure condition, invalid event contract, unsupported event type, expired user approval, wrong resource scope and unknown downstream completion. A generic ‘failed’ label discards information the next operator needs. A model may summarise an error, but the trusted queue and target records should establish the actual reason and event identity.
Do not infer irrecoverability from an attempt counter alone. A message could repeatedly fail because the worker lost its lock or crashed under load, not because its payload is inherently corrupt. Azure’s dead-letter guidance explains that attempts increase after abandoned deliveries or expired locks, and a max-delivery threshold eventually moves the message to a DLQ. Diagnose the infrastructure behaviour before blaming the content.
Conversely, do not try to make an obviously invalid record succeed through hundreds of retries. Unbounded attempts consume capacity, increase cost and can hide legitimate queue work. A bounded policy should stop the loop and preserve enough evidence to repair the cause. A correct refusal to process an unauthorised command can be more valuable than an attractive completion statistic.
Return to contents or continue to AWS SQS redrive policy uses received attempts.
3. AWS SQS redrive policy uses received attempts
Amazon SQS documentation specifies maxReceiveCount as part of the source queue’s redrive policy. A message that receives too many unsuccessful delivery attempts is routed to the configured DLQ. The limit should be chosen with actual processing and transient-failure behaviour in mind rather than set to one merely to generate a convenient dead-letter count.
AWS’s SQS FAQ gives an example in which maxReceiveCount five leads to dead-letter movement after the sixth unsuccessful receive under that example’s semantics. This is an illustrative provider rule, not the rule for every messaging platform. Count receives and visibility-timeout behaviour according to the exact queue configuration. A failed browser screenshot or language-model response is not necessarily an SQS receive attempt.
SQS also provides a redrive workflow to move DLQ messages to the source queue, with a configurable redrive rate. That operational capability does not decide whether the underlying business operation is still authorised. If the message once requested emailing a parent, the receiver should check the original send and current permission before a replay creates another notification.
Keep source and DLQ type compatibility in mind. AWS documentation says standard SQS queues require standard DLQs and FIFO queues require FIFO DLQs. FIFO workflows can also depend on exact order; AWS warns against using a DLQ with FIFO operations when removing a failed message could break the correctness of subsequent ordered steps. The system must protect the business sequence, not simply clear the backlog.
Return to contents or continue to Azure Service Bus has distinct dead-letter reasons.
4. Azure Service Bus has distinct dead-letter reasons
Azure Service Bus maintains a dead-letter subqueue for each relevant queue or subscription. Its documentation lists system reasons including MaxDeliveryCountExceeded, TTLExpiredException, HeaderSizeExceeded and invalid session circumstances. Applications can also dead-letter messages under their own reason codes. These structured reasons offer a starting point for diagnosing why a message stopped normal processing.
Azure describes a default maximum delivery count of ten, configurable for its queue or subscription. Under peek-lock processing, abandoning a message or allowing its lock to expire increases its delivery count; crossing the configured limit moves it to the dead-letter subqueue. A receiver that loses its connection before settlement can therefore produce repeated deliveries without an intrinsically malformed message.
Azure notes that DLQ messages are not automatically cleaned up; they remain until explicitly retrieved and completed or otherwise addressed. That contrasts with any casual assumption that a dead-letter queue is a temporary recycle bin that empties on its own. Operators need ownership, access controls, retention considerations and a deliberate disposition process.
The correct repair follows the actual reason. A missing session identifier is not solved by raising an unrelated timeout, and a user-scope denial should not be bypassed to clear the queue. A system-generated reason may describe a symptom; the application and provider logs still need to establish the underlying sequence and whether a protected effect already occurred.
Return to contents or continue to Delivery counts are not model-quality scores.
5. Delivery counts are not model-quality scores
An agent might make three internal reasoning calls and one queue receive before finishing a task. Another might receive the same event six times because its worker crashes repeatedly. The queue’s receive counter measures delivery attempts under the broker contract, not how many students were helped or how many model answers were correct. Reporting it as an AI success percentage is a denominator error.
One logical business task can create several related events. A source revision might trigger a search-index update, a reviewer notification and an audit event. Each may have a different queue and retry policy. Counting three successful messages as three completed parent requests inflates user value, while counting one dead-lettered audit copy as total failure may overstate harm.
Keep separate identities: original user task, source business operation, event ID, delivery attempt and final external effect. A reliable ledger can join them while preserving their distinct meanings. It allows a responder to ask whether the intended resource is already correct before deciding whether a particular dead-letter message still needs work.
The user-facing report should name the actual outcome. A school notice may already be published even when its search-index event remains dead-lettered. That does not make the indexing issue harmless, but it changes how the service explains the situation. The next useful action might be repairing discoverability, not publishing a duplicate article.
Return to contents or continue to Poison messages and transient outages need different handling.
6. Poison messages and transient outages need different handling
A poison message is persistently unprocessable under the current consumer contract, often because the schema, encoding or expected content cannot be interpreted. Retrying it without modification is unlikely to succeed. A transient failure occurs when the required service or resource is temporarily unavailable while the message itself remains valid. Separating these cases makes recovery more efficient and protects queue capacity.
Suppose an approved document event references a field the upgraded parser no longer accepts. The consumer should record the schema version, event ID and failure reason. A developer can repair a compatibility adapter or appropriately version the event. The model should not invent a missing field merely to make the message pass validation.
Now suppose the same event is valid, but the search provider times out. A bounded retry with suitable backoff may be reasonable after checking idempotency and effects. If the provider could already have accepted the update, the original operation requires reconciliation before another write. A network timeout is an observation limit, not confirmation of no effect.
An access denial is neither poison nor ordinary transient failure. It may mean the event belongs to a different tenant or an approval has expired. The proper outcome can be Refused or Awaiting Authority rather than replayed under an administrator account. A DLQ should not become a route for bypassing security when automatic processing declines a command.
Return to contents or continue to Put idempotency before consequential replay.
7. Put idempotency before consequential replay
Reprocessing a message can be harmless for some carefully designed reads, but repeated external writes can create duplicates. An email might have been accepted before the worker lost its acknowledgement; a WordPress create request might have saved an article under the original ID. The redrive worker needs to distinguish unknown status from confirmed absence before performing a second action.
Use stable event and logical operation IDs. A consumer can record processed event identities and their trusted result under an appropriate transaction or effect ledger. On receiving a redelivered event, it checks whether the intended business operation is already complete. The correct response may be to acknowledge the duplicate without creating another resource.
Idempotency keys have provider-specific scope and retention. An application should not assume that sending the same JSON body to any service automatically deduplicates it. If the provider offers an idempotent endpoint, follow its documented key rules; otherwise reconcile the target by stable resource identity and approved revision. A model-generated suggestion for a new random key can defeat deduplication.
Replaying a message whose original effect is Unknown is not a harmless maintenance action. Preserve the uncertainty, query the original provider receipt or target state, and choose a bounded next action after evidence. A protected message queue cannot itself prove that an external recipient received nothing.
Return to contents or continue to Protect order-sensitive workflows from unsafe redrive.
8. Protect order-sensitive workflows from unsafe redrive
Some tasks depend on event order. A draft can be Approved and later Cancelled, while a revised school notice may supersede an older date. If an earlier failed Approved event is replayed after the later cancellation, a naive consumer could resurrect an action the user has withdrawn. Stable event IDs avoid duplicate handling of one event but do not establish the order between distinct events.
Store source revisions or suitable business sequence numbers. A consumer processing revision 6 should not let a delayed revision 5 overwrite the current state under a monotonic revision contract. The exact rule needs to distinguish historical evidence from the state that governs new actions. A source fact can remain true about yesterday without authorising an action today.
FIFO queue order guarantees have a defined broker and message-group scope. A dead-letter detour can alter the practical processing sequence when a failed message leaves the main path while later messages advance. AWS explicitly warns that FIFO DLQs may be unsuitable where exact ordered operations cannot tolerate this effect. That is a business design decision, not an argument against DLQs in every FIFO workflow.
Before replaying a long-held event, check both source version and current user authority. If its work was superseded or cancelled, record a safe terminal disposition without performing the old external effect. Clearing the DLQ count is not worth undoing a valid later user decision.
Return to contents or continue to Authorization must survive queue delays.
9. Authorization must survive queue delays
An event can be authentic and still describe an operation that is no longer permitted. A parent may withdraw a request or a reviewer may approve only one document revision while a message waits for recovery. The next consumer attempt is another potential external action and must use current permission checks where the task requires them.
Bind the intended target, recipient and content version to an authoritative grant. A message saying Publish article P-41 revision 3 should not publish revised content under revision 4 simply because both share a title. If the effect changed materially, the applicable approval may need renewal. The broker’s delivery count supplies no evidence of human consent.
Cross-tenant isolation matters even in maintenance tools. A global DLQ viewer may contain events for several schools. A Cedar operator should not be able to inspect Willow’s private payloads or redrive them with broad service privileges. Access to DLQ content, replay commands and diagnostic exports should follow the same trust boundaries as the original tasks.
Use safe metadata in ordinary monitoring. An operator often needs the event ID, redrive count, error class and source revision, not an entire private learner record. A qualified investigation can access protected evidence through an appropriate route. A retry dashboard should not become an accidental archive of personal conversations.
Return to contents or continue to A fictional 120-message recovery ledger.
10. A fictional 120-message recovery ledger
Consider an invented Cedar Learning Events test containing 120 logical events. Seventy-two have independently verified intended outcomes. Eighteen have recoverable transient errors and remain eligible for controlled retry. Twelve are held as schema-incompatible poison messages. Ten have reached the DLQ after repeated processing attempts and need cause analysis. Eight have uncertain external effects, so blind replay is prohibited.
Check the mutually exclusive categories: 72 + 18 + 12 + 10 + 8 = 120. Verified completion is 72 ÷ 120 = 60%. Transient retry candidates are 18 ÷ 120 = 15%; schema poison cases 12 ÷ 120 = 10%; repeated-failure DLQ cases 10 ÷ 120 ≈ 8.33%; unknown-effect cases 8 ÷ 120 ≈ 6.67%. The figures are deliberately chosen teaching values, not live queue traffic or measured AI safety.
Twenty-two of the invented events are in distinct DLQ problem categories, but that does not mean twenty-two users were harmed or twenty-two model answers were incorrect. One event may concern a background search index, while another concerns a protected communication. Consequence and user outcome require their own evidence. An aggregate DLQ count cannot establish whether the business task ultimately succeeded.
Do not count the eighteen retry-eligible events as completed merely because they have not yet reached the dead-letter limit. Equally, a message safely held for human permission should not be forced into processing to raise throughput. The ledger’s value lies in matching each event to a precise next decision, not maximising the number marked green.
Return to contents or continue to Use a table to give each case a responsible next action.
11. Use a table to give each case a responsible next action
An operational table should separate verified effect, transient retry, poison schema, repeated-attempt DLQ and unknown downstream effect. The first requires no new side effect, the second may need bounded retry, the third needs contract repair, the fourth diagnosis of worker or payload failure, and the fifth independent reconciliation. Treating all five as one Failed status would create a dangerous one-button Redrive All temptation.
Preserve event ID, parent task, source version, trusted error reason, attempt count and latest verified target state under appropriate access controls. A model can draft a human-readable summary for an engineer, but the table must derive its status from the actual broker and provider records. A plausible generated explanation cannot substitute for an external receipt.
Name the owner. An API developer may correct schema compatibility, an operations engineer may repair a lost receiver lock, and a qualified editor may decide whether an old notice still deserves publication. Automatic retries are useful only when the condition and authority are genuinely satisfied. An unresolved case should retain an accountable path rather than disappear when the queue age increases.
Track snapshots carefully. The test ledger describes one artificial cutoff. A later corrected event can change categories without altering the number of original logical events. This supports transparent recovery accounting, especially when operations are observed long after their initial attempted execution.
| Message disposition | Events | Share | Next action |
|---|---|---|---|
| Independently verified outcome | 72 | 60.00% | No new effect |
| Transient error; bounded retry eligible | 18 | 15.00% | Recheck source and capacity |
| Schema-poison message | 12 | 10.00% | Repair versioned consumer |
| Repeated-attempt DLQ | 10 | 8.33% | Diagnose settlement or payload |
| External result unknown | 8 | 6.67% | Reconcile original operation |
| All logical events | 120 | 100.00% | Fictional fixed denominator |
Return to contents or continue to A controlled redrive exercise with conservation.
12. A controlled redrive exercise with conservation
Suppose nine of the twelve schema-poison events are repaired with a compatible consumer and independently verified after bounded redrive. Under the original event population, verified outcomes rise from seventy-two to eighty-one, and schema-poison cases fall from twelve to three. Transient candidates remain eighteen, repeated-failure cases ten and unknown effects eight.
Check the revised population: 81 + 18 + 3 + 10 + 8 = 120. Verified completion becomes 81 ÷ 120 = 67.5%. The improvement is evidence about the nine repaired fictional events, not proof that the previous system had a 67.5% production reliability rate. It should be recorded as a later snapshot rather than a rewrite of what was known at the first cutoff.
Another approach would be to count the nine redrive attempts as nine new tasks. That would inflate the denominator and hide their connection to earlier failures. Retain stable logical IDs and treat each delivery attempt as a child event of the original. Cost and retry-volume metrics can count attempts separately without corrupting the outcome report.
Do not perform the redrive simply to replicate this arithmetic in production. A genuine replay requires validation that the schema fix works, the correct resource revision remains applicable and no earlier external effect completed unnoticed. The experimental numbers illustrate how to report repaired work, not an instruction to replay every queued message.
Return to contents or continue to Watch backlog age, not only backlog size.
13. Watch backlog age, not only backlog size
A DLQ containing five messages that affect an imminent school deadline may demand attention sooner than one containing many harmless expired preview refreshes. Count matters, but age, cause, consequence, tenant and user commitments also matter. A practical dashboard can report the oldest unresolved item and classify severity under the organisation’s operational rules.
A monotonically growing DLQ can consume broker storage and conceal systemic errors. Azure’s documentation notes that messages remain until explicitly settled or addressed, so absent cleanup is not a safe operational plan. SQS has its own retention and redrive configurations. Choose policies based on the actual provider rather than assume all queues delete themselves after one common period.
Alert fatigue is another risk. A worker failing hundreds of copies of the same unsupported schema may generate many repeated notifications. Group by root cause while preserving affected business IDs. An incident responder needs to know whether one incompatibility affects many tasks, and whether any of them require immediate human action.
Monitor the main queue as well. Moving poison messages to a DLQ can improve normal throughput while leaving user obligations unfinished. A green main-queue lag metric should not be used to declare that every task is complete. Pair broker health with verified source-to-target outcomes and a DLQ remediation owner.
Return to contents or continue to Safe replay starts with a source-of-truth check.
14. Safe replay starts with a source-of-truth check
The original message may describe a state that is no longer current. Before replay, check the authoritative record: is the document still active, which revision governs, did the user cancel, and has the target already been updated? A repaired parser can faithfully process an obsolete event unless it also enforces business validity.
Use dry-run or sandbox validation where supported. A synthetic event can pass through the updated consumer with external effects disabled to demonstrate schema compatibility. Then a permitted real event can be processed once with appropriate state checks. A model’s generated statement that the bug was fixed is not an adequate substitute for a controlled provider and target observation.
Redrive rates also matter. Moving thousands of repaired messages to the source queue at maximum speed can overload a downstream API or trigger rate limits. AWS supports configuring SQS redrive velocity. Plan throughput according to service capacity and task consequence, with a stop condition if error rates or unsafe side effects appear.
Preserve a roll-forward plan. If a previously missed search update is no longer necessary because a newer complete index exists, the responsible outcome may be Superseded rather than Replayed. A good ledger can document this decision with the source generation that replaced it. Event replay serves the user task, not the queue counter.
Return to contents or continue to Unknown effects belong in reconciliation, not a normal retry loop.
15. Unknown effects belong in reconciliation, not a normal retry loop
Imagine a message worker submits an approved parent email, the provider accepts it, and the acknowledgement is lost. The worker cannot prove whether delivery occurred. Requeueing the identical message may cause a second email. If the message reaches a DLQ after repeated uncertain attempts, increasing maxReceiveCount does not resolve the underlying lack of effect evidence.
Preserve the original provider operation or message identity. Check an authoritative send or saved-item record where the integration permits, then decide whether the intended effect already happened. An idempotency-aware endpoint can help under its documented key scope. If no reliable readback exists, a qualified human or controlled follow-up may be needed.
The user-facing status should reflect evidence rather than wishful completion. ‘Your message was accepted for processing but final delivery is unverified’ is more precise than ‘sent’ if the provider has not confirmed it. A deadline or school notice may be consequential enough to require additional verification before a parent relies on it.
Do not let the model declare unknown outcomes complete because an earlier conversation summary says the task is done. The receipt is a trusted tool fact with an identity and time. A dead-letter repair workflow is often a workflow-state and authorization problem, not merely a broker configuration problem.
Return to contents or continue to Changed-context school publisher with forty tasks.
16. Changed-context school publisher with forty tasks
Transfer the method to a fictional school content publisher with forty logical tasks. Twenty-four have verified live or draft target states matching user intent, six have transient provider failures, five are held for invalid schema fields, three are correctly blocked because approval is missing, and two have uncertain publication results. The count is 24 + 6 + 5 + 3 + 2 = 40.
Verified outcomes represent 24 ÷ 40 = 60%. Transient failures are 15%, schema holds 12.5%, permission refusals 7.5% and unknown outcomes 5%. The figures are constructed to teach different next actions. A missing editor approval is not a poison payload to repair through retries, and an unknown publication cannot be treated as an absent post without checking the original WordPress ID.
Now update the provider schema so the five held items become valid. Before processing them, one editor withdraws approval for a different item. The safe system rechecks the actual grant at execution time rather than simply increasing the queue’s receive limit. Replay eligibility depends on current user authority and resource state, not whether the event’s JSON now parses.
Suppose one of the two unknown post creations is found already published at its original canonical slug. The right action is to record Verified Complete for that logical task, not create a second article with a suffixed URL. This transfer illustrates why durable identity and readback make message recovery useful rather than duplicative.
Return to contents or continue to Test the DLQ workflow using controlled failure injection.
17. Test the DLQ workflow using controlled failure injection
Create synthetic messages for a malformed schema, a transient provider timeout, an expired approval, a worker lock lost before settlement and an externally committed effect with a lost acknowledgement. Observe which ones retry, dead-letter, refuse or reconcile under the intended policy. The test environment must not send live parent emails or update the public website.
Inspect actual broker delivery counts and the consumer’s target-state ledger. A model’s predicted sequence is not enough to establish what happened. Test receiving a message repeatedly until it reaches the configured limit, then repair it and redrive under a valid current source revision. Confirm the item does not create duplicate effects and that other queue work remains available.
Include an ordered-event case. Put Approved revision 5 into the DLQ, process Cancelled revision 6 normally, then attempt a redrive of revision 5. The consumer should preserve the newer governing state rather than resurrect approval. This tests the source-version rule independently of message deduplication.
After repair, preserve the failing synthetic fixture as a regression test. A broker configuration, SDK, schema or model change may reintroduce the same issue. Positive controls should also verify that permitted normal messages still complete; a system that refuses everything is not a useful education service.
Return to contents or continue to Privacy, retention and access of a DLQ.
18. Privacy, retention and access of a DLQ
A dead-letter payload can contain personal correspondence, identifiers or an entire document snapshot. Isolating it from the main queue does not make it public or harmless. Apply access controls, encryption, appropriate retention and redaction to the DLQ and its diagnostic tools under the actual service and privacy requirements.
An operator often needs the error class, event ID, source record and safe provenance before viewing the sensitive payload. Protect broader inspection through a qualified role and audit access where appropriate. A global Redrive All control available to every on-call worker can create both permission and availability risks.
Deleting a DLQ message is also a decision. It can be legitimate after verified completion, explicit supersession or an approved retention rule; it can be harmful if the user task remains unresolved and no owner accepted responsibility. Do not turn clearing a queue into erasing the evidence required for later correction.
Logs, alerts and exported incident summaries may create additional copies. The Sensitive Log Redaction chapter explains why copying full event payloads into general dashboards is not necessary for trustworthy operations. Use safe identifiers and restricted evidence routes.
Return to contents or continue to Implement a small but accountable recovery runbook.
19. Implement a small but accountable recovery runbook
Begin by documenting the source queue, DLQ, max-delivery or redrive policy, message identity, owning consumer and target business effects. Define error categories, retryable conditions, current authorization checks and the evidence required to mark one logical task complete. A runbook should be precise enough that a second operator can distinguish a schema error from a lost acknowledgement.
Assign owners for the different stages. A producer may need to correct an event schema, a consumer owner may fix lock settlement, an editor may determine whether a school notice remains applicable, and an incident responder may reconcile an unexpected external effect. A language model can help summarise the work but should not invent missing permissions or provider receipts.
Choose bounded replay and stop conditions. If corrected events still fail under the same reason, pause redrive and investigate before saturating the queue again. If a new privacy denial appears, do not substitute an administrator identity. If the source revision was superseded, decide whether the original message should be safely retired under the business contract.
The enduring principle is that a DLQ preserves a question for accountable resolution. Did the original task complete, does the message still apply, may it be executed now and can the final effect be verified? A system that answers those questions protects readers far better than one that merely moves messages until a dashboard counter reaches zero.
Return to contents.
Frequently asked questions
What is a dead-letter queue in an AI workflow?
A separate queue or subqueue used for messages that cannot complete normal processing, preserving them for investigation and controlled disposition.
Does moving a message to a DLQ mean the user task failed forever?
No. It may be repairable, already externally complete, superseded, or require qualified human review.
Can a valid message be dead-lettered because a worker lost its lock?
Yes. Azure Service Bus documentation describes repeated deliveries after expired locks and lost settlements.
Should an operator redrive all DLQ messages after a fix?
Not blindly. Check source revisions, current approvals, prior external effects, provider semantics and bounded capacity first.
Do DLQs preserve FIFO application ordering automatically?
Not for every workflow. AWS cautions that moving messages out of a FIFO path can break strict business order.
Can a retry repair missing user authorisation?
No. A permission denial requires a legitimate current grant or a protected refusal, not another attempt with wider privileges.
Official provider guidance
Sources reviewed on 24 October 2026. AWS and Azure examples have different provider-specific receive, settlement and retention rules. All Cedar examples, attempt counts and derived percentages are invented educational data, not measurements from a deployed service.
- AWS SQS — Using Dead-Letter Queues: Redrive policies, maxReceiveCount, DLQ queue types and ordering limitations.
- Amazon SQS FAQ: Original message identity, redrive and redrive-rate choices.
- Azure Service Bus — Dead-Letter Queues: Dead-letter reasons, lock settlement, max-delivery and DLQ cleanup semantics.
- Azure Service Bus — Message Transfers, Locks and Settlement: Receive modes and retry effects around lost locks.
- AWS Lambda — SQS Error Handling: Batch handling, visibility and response semantics.
- NIST AI RMF Playbook — Manage: Accountable incident response and monitored AI operation.
Related specialist reading
Continue with Super Intelligence curriculum; Transactional Outbox; Event-Driven Agents; Agent Cancellation; Batch Writes; Sensitive Log Redaction; Secondary Mathematics Tutorials. A dead-letter message is an unresolved business question, not permission for unlimited replay.