Moving a failed message to a dead-letter queue can keep a worker from repeatedly tripping over the same problem. It does not complete the work that message represented. If nobody notices the queue filling up, the system has become better at hiding unfinished business.
The Amazon SQS guidance describes isolating unsuccessful messages, investigating the cause and redriving them. Receive thresholds and retention need deliberate choices. A queue that discards the evidence before anyone can investigate is not giving the team much of a recovery window.
I would give the queue an owner, an actionable alert and a short process for deciding what happens next. Some messages can be retried after a fix; others need correcting or a separate business decision. Replaying everything without understanding the failure can reproduce the same problem, and repeated processing still needs to handle side effects safely.
The reassuring state is that failed work is visible and has a route back into the system. “The main queue is empty” is not enough if the dead-letter queue contains the orders, imports or notifications people are waiting for. Check the place the failures went before declaring the job finished.