# Amazon SQS error handling and problematic messages
<a name="best-practices-error-handling"></a>

This topic provides detailed instructions on managing and mitigating errors in Amazon SQS, including techniques for handling request errors, capturing problematic messages, and configuring dead-letter queue retention to ensure message reliability.

****Topics****
+ [Handling request errors in Amazon SQS](handling-request-errors.md)
+ [Capturing problematic messages in Amazon SQS](capturing-problematic-messages.md)
+ [Setting-up dead-letter queue retention in Amazon SQS](setting-up-dead-letter-queue-retention.md)

# Handling request errors in Amazon SQS
<a name="handling-request-errors"></a>

To handle request errors, use one of the following strategies:
+ If you use an AWS SDK, you already have automatic *retry and backoff* logic at your disposal. For more information, see [Error Retries and Exponential Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) in the *Amazon Web Services General Reference*.
+ If you don't use the AWS SDK features for retry and backoff, allow a pause (for example, 200 ms) before retrying the [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) action after receiving no messages, a timeout, or an error message from Amazon SQS. For subsequent use of `ReceiveMessage` that gives the same results, allow a longer pause (for example, 400 ms). 

# Capturing problematic messages in Amazon SQS
<a name="capturing-problematic-messages"></a>

To capture all messages that can't be processed, and to collect accurate CloudWatch metrics, configure a [dead-letter queue](sqs-dead-letter-queues.md).
+ The redrive policy redirects messages to a dead-letter queue after the source queue fails to process a message a specified number of times.
+ Using a dead-letter queue decreases the number of messages and reduces the possibility of exposing you to *poison pill* messages (messages that are received but can't be processed).
+ Including a poison pill message in a queue can distort the [`ApproximateAgeOfOldestMessage`](sqs-available-cloudwatch-metrics.md) CloudWatch metric by giving an incorrect age of the poison pill message. Configuring a dead-letter queue helps avoid false alarms when using this metric.

# Setting-up dead-letter queue retention in Amazon SQS
<a name="setting-up-dead-letter-queue-retention"></a>

For standard queues, the expiration of a message is always based on its original enqueue timestamp. When a message is moved to a dead-letter queue, the enqueue timestamp is unchanged. The `ApproximateAgeOfOldestMessage` metric indicates when the message moved to the dead-letter queue, *not* when the message was originally sent. For example, assume that a message spends 1 day in the original queue before it's moved to a dead-letter queue. If the dead-letter queue's retention period is 4 days, the message is deleted from the dead-letter queue after 3 days and the `ApproximateAgeOfOldestMessage` is 3 days. Thus, it is a best practice to always set the retention period of a dead-letter queue to be longer than the retention period of the original queue.

For FIFO queues, the enqueue timestamp resets when the message is moved to a dead-letter queue. The `ApproximateAgeOfOldestMessage` metric indicates when the message moved to the dead-letter queue. In the same example above, the message is deleted from the dead-letter queue after 4 days and the `ApproximateAgeOfOldestMessage` is 4 days.