Introduction

Amazon SQS does not give you a perfectly real-time queue length, but it does expose useful approximate counts. In practice, those attributes are good enough for dashboards, alarms, and autoscaling decisions as long as you understand what each number means.

Which SQS Attributes Matter

The three most useful queue counters are:

• 'ApproximateNumberOfMessages: messages currently available to be received'
• 'ApproximateNumberOfMessagesNotVisible: messages being processed and hidden by the visibility timeout'
• 'ApproximateNumberOfMessagesDelayed: messages still waiting for a delay period to expire'

These values are approximate because SQS is a distributed service. You should treat them as operational signals, not exact accounting data.

Reading the Count with Boto3

The simplest programmatic method is get_queue_attributes. You ask for the attributes directly from SQS and convert the returned strings to integers.

1import boto3
2
3sqs = boto3.client("sqs", region_name="us-east-1")
4queue_url = "https://sqs.us-east-1.amazonaws.com/123456789012/orders"
5
6response = sqs.get_queue_attributes(
7    QueueUrl=queue_url,
8    AttributeNames=[
9        "ApproximateNumberOfMessages",
10        "ApproximateNumberOfMessagesNotVisible",
11        "ApproximateNumberOfMessagesDelayed",
12    ],
13)
14
15attributes = response["Attributes"]
16available = int(attributes["ApproximateNumberOfMessages"])
17in_flight = int(attributes["ApproximateNumberOfMessagesNotVisible"])
18delayed = int(attributes["ApproximateNumberOfMessagesDelayed"])
19
20total_observed = available + in_flight + delayed
21
22print(f"available={available}")
23print(f"in_flight={in_flight}")
24print(f"delayed={delayed}")
25print(f"observed_total={total_observed}")

This is usually the right answer when the goal is, "How many messages are in or around this queue right now?"

AWS CLI Equivalent

For quick checks in a terminal or CI job, the AWS CLI is often enough.

aws sqs get-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/orders \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible ApproximateNumberOfMessagesDelayed

That command returns JSON with the same attribute names. It is useful for operational scripts, but the values still have the same approximate semantics as the SDK call.

CloudWatch Versus Queue Attributes

You can also monitor queue depth through CloudWatch metrics, which is convenient for alarms and dashboards. The distinction is operational: get_queue_attributes is a direct query you make right now, while CloudWatch is better for historical trends and alerting.

For example, if you want an alarm when backlog grows beyond a threshold for several minutes, CloudWatch is the better tool. If you want your application or admin script to display the current approximate depth, queue attributes are simpler.

Interpreting the Numbers Correctly

A queue with 0 available messages is not necessarily idle. It may still have many in-flight messages being processed by consumers. That is why ApproximateNumberOfMessagesNotVisible matters. If that number is high and stable, your workers may be slow, stuck, or timing out before deleting messages.

Likewise, delayed messages are real backlog, but they are not yet eligible for delivery. If you ignore the delayed count, your dashboard may understate upcoming work.

For autoscaling, teams often watch both available and not-visible counts. Available messages indicate immediate backlog. Not-visible messages indicate work already handed to consumers. Looking at both tells you whether the system is overwhelmed or merely busy.

Common Pitfalls

• Treating the SQS counts as exact values leads to brittle logic because the attributes are explicitly approximate.
• Looking only at ApproximateNumberOfMessages can hide a large number of in-flight messages.
• Forgetting delayed messages makes the queue look emptier than it really is.
• Building business invariants around queue depth is risky because these metrics are for operations, not strict correctness.
• Missing sqs:GetQueueAttributes permission causes confusing failures that look like missing queues or broken SDK code.

Summary

• The main SQS counters are available, not-visible, and delayed message counts.
• 'get_queue_attributes in Boto3 is the simplest way to fetch them programmatically.'
• The AWS CLI can retrieve the same information for manual checks or automation.
• Queue depth is approximate, so use it for monitoring and scaling, not exact bookkeeping.
• A useful operational view usually combines available, in-flight, and delayed counts.