SQS queues with no traffic, and why an empty queue is not proof of idleness

Why depth zero can mean a healthy queue

The tempting test for an unused queue is “no messages waiting”. It is wrong. A queue whose consumers keep up with producers drains almost instantly, so it reads close to zero while handling millions of messages. The SQS CloudWatch metrics reference describes ApproximateNumberOfMessagesVisible as the current backlog, while NumberOfMessagesSent counts messages successfully added. Only the second tells you whether anyone is using the queue.

Measuring sends instead of backlog

aws cloudwatch get-metric-statistics \
  --namespace AWS/SQS --metric-name NumberOfMessagesSent \
  --dimensions Name=QueueName,Value=my-queue \
  --start-time 2026-08-26T00:00:00Z --end-time 2026-09-25T00:00:00Z \
  --period 86400 --statistics Sum

aws sqs get-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/111122223333/my-queue \
  --attribute-names ApproximateNumberOfMessages RedrivePolicy

AWS notes that SQS metrics are emitted only while a queue is active, so a series with no datapoints at all over a month is itself a signal. Check NumberOfMessagesReceived too, and remember that messages moved to a dead-letter queue by a redrive policy are not counted as sends to that queue.

Where the check stands today

ZopNight gathers the send and depth metrics for every queue, but the check does not raise a recommendation. The earlier version treated an empty queue as idle, which would have flagged efficient, busy queues for deletion. Even with the throughput metrics in hand, the next problem remains: there is no money to recover.

Why no saving is possible

Amazon SQS pricing says you pay only for what you use and there is no minimum fee; every customer gets 1 million requests free each month. A queue that receives no messages makes no billable requests, so its monthly cost is zero. ZopNight reports cost recommendations only when the saving is a real figure, and zero is not one.

What stays out of scope

Dead-letter queues, FIFO queues and standard queues are all treated the same: none produces a finding from this check. If you want a hygiene list, build it from the send metric above.

Deleting a queue that is truly abandoned

1. Confirm no producer is expected to send: search code, infrastructure templates and SNS subscriptions for the queue URL or ARN.
2. Check whether it is the dead-letter target of another queue’s RedrivePolicy.
3. List Lambda triggers with aws lambda list-event-source-mappings --event-source-arn and the queue ARN, and remove them.
4. Delete it with aws sqs delete-queue --queue-url and the URL.