Available CloudWatch metrics for Amazon SQS

For standard queues, if a message is received three or more times and not deleted, SQS moves it to the back of the queue. The metric then reflects the age of the next message that hasn’t exceeded the receive threshold. This reordering occurs even when a redrive policy is in place.

Poison-pill messages (those repeatedly received but never deleted) are excluded from this metric until successfully processed.

When a message is moved to a DLQ after exceeding the maxReceiveCount, the age resets. In that case, the DLQ’s metric reflects the time the message was moved—not when it was originally sent.

FIFO queues don't reorder messages to preserve order. A failed message blocks its message group until it's deleted or expires. If a DLQ is configured, the message is sent there after the receive threshold is met.

A message is considered in-flight after it’s received from the queue by a consumer but not yet deleted or expired.

This metric helps you troubleshoot and optimize FIFO queue throughput. High values usually indicate strong concurrency.

If the queue has a large backlog and this value remains low, consider scaling consumers or increasing the number of active message groups.

For throughput and in-flight limits, see Amazon SQS quotas.

Applies to queues configured with a default delay and to individual messages sent with a DelaySeconds parameter.

Delayed messages remain hidden from consumers until their delay period expires, which can affect perceived queue backlog or throughput.

Messages enter the in-flight state after being sent to a consumer via the ReceiveMessage API.

These messages are temporarily hidden from other consumers during the visibility timeout window.

Use this metric to track message processing delays or stuck consumers.

Reflects the current processing backlog in the queue.

There's no hard limit on how many messages can accumulate, but they are subject to the queue’s configured retention period.

A consistently high value may indicate under-provisioned consumers or stuck processing logic.

This metric can help identify inefficiencies in polling behavior or underutilized consumer instances.

High values may occur when the queue is empty, the consumer uses short polling, or messages are being processed faster than they are produced.

This isn't a precise indicator of queue state. It reflects service-side behavior and may include retries.

SQS deduplicates messages based on the MessageDeduplicationId or content-based hashing (if enabled).

A high value may indicate that a producer is repeatedly sending the same message within the 5-minute deduplication window.

Use this metric to troubleshoot redundant producer logic or confirm that deduplication is functioning as intended.

This metric counts all successful delete operations—even if the same message is deleted more than once.

Common reasons for higher-than-expected values include:

Use this metric to track message processing success, but don't treat it as an exact count of unique deleted messages.

This includes all messages returned to consumers, including those that are later returned to the queue due to visibility timeout expiration.

A single message can be received multiple times if it isn’t deleted, which can cause this metric to exceed the number of messages sent.

Use this to track consumer activity, but don't treat it as a count of unique messages processed.

Manual calls to SendMessage or SendMessageBatch are counted, including those targeting a DLQ directly.

Messages that are automatically moved to a DLQ after exceeding the maxReceiveCount are not included in this metric.

As a result, NumberOfMessagesSent may be lower than NumberOfMessagesReceived—especially if redrive policies are moving many messages to DLQs behind the scenes.

This metric will not appear in the CloudWatch console until the queue receives its first message.

Use this metric to track the size of each message in bytes. This is useful for analyzing payload trends or estimating throughput cost.

The maximum message size for SQS is 256 KB.

Helps identify potential noisy neighbor problems in multi-tenant environments by tracking message groups consuming disproportionate resources.

Use this metric to set alarms that trigger when the number of noisy groups exceeds your acceptable threshold, indicating potential queue fairness issues.

Provides visibility into the queue backlog for standard-rate message groups, excluding messages from noisy neighbors.

Helps identify the true processing backlog for typical message groups by filtering out the impact of noisy neighbors.

Tracks in-flight messages (being processed but not yet deleted) from well-behaved message groups.

Use this metric to monitor processing throughput of normal message groups and detect processing bottlenecks that aren't caused by noisy neighbors.

Helps monitor the delayed message backlog from message groups with normal or expected throughput patterns (as opposed to high-volume or noisy groups)

Useful for understanding future processing requirements and capacity planning for typical workloads.

Used for monitoring SLA compliance and detecting processing bottlenecks in message groups with normal or expected throughput patterns (as opposed to high-volume or noisy message groups that might otherwise skew the metric).

Use this metric to set alarms for message processing timeouts that ignore artificially aged messages from noisy neighbors.