Dead-letter queue

A dead-letter queue, often shortened to DLQ, isolates events or jobs that could not be processed after the permitted attempts. It keeps one malformed or persistently failing item from blocking the main flow while preserving enough context for a person or repair process to investigate.

The control record should show the source queue, message identity, property or account scope, original receipt time, failure code, attempt count, last attempt, retention deadline, assigned owner, and replay decision. Sensitive payloads should be minimized or protected. A DLQ is not an archive and not a substitute for an alert.

Suppose a webhook reports a lease charge for a unit identifier that no longer maps to the accounting file. After bounded retries, the event moves to the DLQ. The landlord or support owner corrects the mapping, previews the effect, and replays that one item. Blindly replaying the whole queue could post obsolete events or duplicate items already repaired manually.

Evaluate whether the product exposes queue age and count, alerts before retention expires, supports item-level inspection, and requires authorization for replay. A claim that failed events “go to a queue” is incomplete when nobody owns it or when redrive bypasses idempotency and reconciliation.