SQS CloudWatch Alarm on Age of Oldest Message (2026)

This alarm is firing because the oldest message in your SQS queue is older than the configured threshold, indicating a potential backlog and processing delay.

Common Causes and Fixes:

1. Under-provisioned Consumers:

   • Diagnosis: Check your consumer application’s logs for signs of errors, high latency, or a lack of activity. Monitor the ApproximateNumberOfMessagesInProgress metric in CloudWatch for your SQS queue. If this number is consistently low or zero while ApproximateNumberOfMessages is high, your consumers aren’t keeping up.
   • Fix: Increase the number of consumer instances or threads. If using autoscaling, adjust your scaling policies to react more aggressively to queue depth. For example, if using EC2, add more instances to your Auto Scaling Group. If using Lambda, increase the ReservedConcurrency or allow it to scale up.
   • Why it works: More consumers mean more parallel processing power to dequeue and process messages, reducing the time any single message spends in the queue.

2. Consumer Application Errors/Deadlocks:

   • Diagnosis: Examine consumer application logs for exceptions, stack traces, or recurring error patterns. Look for messages that are repeatedly received, processed unsuccessfully, and then become visible again after their visibility timeout. Check the ApproximateNumberOfMessagesVisible and ApproximateNumberOfMessagesNotVisible metrics. A high NotVisible count relative to Visible might indicate messages are being received but not deleted successfully.
   • Fix: Debug and resolve errors within your consumer application. Ensure that messages are explicitly deleted from the queue using DeleteMessage after successful processing. If processing fails, implement a robust retry mechanism or send the message to a Dead-Letter Queue (DLQ) for later analysis.
   • Why it works: Unhandled exceptions or logic errors prevent the DeleteMessage call, causing messages to reappear after their visibility timeout, artificially inflating the age of the oldest message.

3. Long Processing Times:

   • Diagnosis: Profile your consumer application to identify bottlenecks. Measure the average and P95/P99 processing time for individual messages. If this time exceeds the SQS visibility timeout, messages will become visible again before they can be deleted.
   • Fix: Optimize your message processing logic. This might involve improving database queries, reducing external API calls, or parallelizing work within a single consumer instance. Alternatively, increase the SQS visibility timeout to a value safely above your maximum expected processing time. For example, if your longest processing time is 5 minutes, set the visibility timeout to 6 minutes (360 seconds).
   • Why it works: A longer visibility timeout gives consumers more time to process a message before it’s returned to the queue. Optimizing processing time ensures messages are handled efficiently within the existing timeout.

4. Incorrect Visibility Timeout Configuration:

   • Diagnosis: Review the visibility timeout setting for your SQS queue in the AWS console or via the AWS CLI (aws sqs get-queue-attributes --queue-url <your-queue-url> --attribute-names VisibilityTimeout). Compare this to your consumer’s typical message processing duration.
   • Fix: Adjust the visibility timeout to be longer than the maximum time it takes your consumer to process a message. For example, if your longest processing time is 2 minutes, set the visibility timeout to 120 seconds. Be cautious not to set it excessively high, as this can mask processing issues.
   • Why it works: The visibility timeout determines how long a message is hidden from other consumers after being received. If it’s too short, messages are returned to the queue prematurely, increasing their age.

5. Network Connectivity Issues (Consumer to SQS):

   • Diagnosis: Check network configurations between your consumer instances and the SQS service endpoint. Ensure security groups, Network ACLs, and VPC routing tables allow outbound traffic to sqs.<region>.amazonaws.com on port 443. Look for network-related errors in consumer logs or instance system logs.
   • Fix: Correct any misconfigurations in security groups, NACLs, or routing. Ensure your consumers have a reliable network path to AWS SQS endpoints. This might involve updating firewall rules or checking NAT gateway configurations.
   • Why it works: Intermittent network problems can prevent consumers from successfully deleting messages, causing them to become visible again and their age to increase.

6. SQS Service Throttling (Less Common for Age, but Possible):

   • Diagnosis: While SQS is highly available, extreme bursts of activity could theoretically lead to temporary delays in message visibility or deletion acknowledgments reaching the service. Check SQS metrics for ThrottledRequests.
   • Fix: If you are consistently hitting throttling limits, consider increasing your SQS throughput by using a FIFO queue (if ordering is required) or sharding your workload across multiple standard queues. For standard queues, ensure your producer is not sending messages faster than your consumers can process them over a sustained period.
   • Why it works: While SQS is designed for high throughput, sustained extreme loads could theoretically contribute to processing delays if downstream consumers are also struggling. Addressing the consumer bottleneck is usually the primary fix.

7. Dead-Letter Queue (DLQ) Configuration Issues:

   • Diagnosis: If you have a DLQ configured, check the DLQ itself. If messages are accumulating there, it indicates a persistent processing failure in your primary consumer. Also, review the maxReceiveCount on the source queue. If it’s set too low, messages might be sent to the DLQ prematurely due to transient issues.
   • Fix: Investigate and fix the underlying issues causing messages to fail processing and be sent to the DLQ. If maxReceiveCount is too low, increase it to a more appropriate value (e.g., 5-10) to allow for transient processing glitches.
   • Why it works: Messages repeatedly failing to be deleted and exceeding maxReceiveCount are moved to the DLQ. If the primary queue is empty but the DLQ is filling, it means the original processing is failing, not necessarily that the queue is just slow.

The next error you’ll likely encounter if you fix the backlog is NumberOfMessagesSent dropping to zero, potentially triggering an alarm if you have one configured for that.