CloudWatch Metric Guide
ApproximateNumberOfMessagesVisibleAmazon SQS CloudWatch metric
ApproximateNumberOfMessagesVisible reports the number of messages currently available to be received from the queue — the standard "queue depth" metric most SQS dashboards lead with.
What it measures
About ApproximateNumberOfMessagesVisible
ApproximateNumberOfMessagesVisible reports the number of messages currently available to be received from the queue — the standard "queue depth" metric most SQS dashboards lead with.
| Namespace | AWS/SQS |
| Metric name | ApproximateNumberOfMessagesVisible |
| Unit | Count |
| AWS docs | Official Amazon SQS metrics reference |
Why this metric matters
Depth is context, not a primary incident signal on its own — it's normal and expected to spike when a producer flushes a batch, traffic bursts, or a scheduled job enqueues a day's work at once. None of that alone is an incident. What matters is the trend: depth that grows and keeps growing, without recovering, means consumers aren't keeping pace with arrivals, regardless of the absolute number.
Used alongside ApproximateAgeOfOldestMessage, depth adds the "how much backlog" context that age alone doesn't give — age tells you if the oldest message is stuck, depth tells you the scale of what's waiting behind it.
Recommended alarm threshold for ApproximateNumberOfMessagesVisible
Recommended threshold
Sustained upward trend over 15+ minutes, evaluated with metric math against a rolling baseline rather than a fixed count
AWS does not publish a universal depth threshold because normal queue depth varies enormously by workload — a healthy batch-processing queue and a healthy real-time queue have very different baselines. A trend-based alarm (ConvOps recommendation) — depth still climbing after 15 minutes rather than a spike that recovers — distinguishes a genuine backlog from the normal sawtooth pattern of batch producers.
Is your ApproximateNumberOfMessagesVisible alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including ApproximateNumberOfMessagesVisible — in 5 minutes.
Common failures that show up in ApproximateNumberOfMessagesVisible
When ApproximateNumberOfMessagesVisible reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Consumer count reduced — an autoscaling policy or manual change scaled down consumers (Lambda concurrency, ECS task count) below what current throughput requires
Producer burst exceeding normal capacity — a marketing push, migration, or upstream retry storm enqueues messages faster than the steady-state consumer fleet is sized for
Consumer errors causing message returns — messages are received but fail processing, returning to the queue after the visibility timeout and re-appearing as visible
Downstream throttling — consumers are rate-limited by a database or third-party API, so they intentionally slow their own receive rate, letting depth build up
How the Nuberio Audit checks ApproximateNumberOfMessagesVisible
The free Audit scans every Amazon SQS resource in your account and checks whether a ApproximateNumberOfMessagesVisible alarm exists, whether its threshold and evaluation period are configured sensibly, and flags it if it's missing entirely. Every finding comes with the exact CLI command to fix it — read-only access, no credit card, results in about 5 minutes.
Nuberio Audit
Scans your CloudWatch setup for missing or misconfigured ApproximateNumberOfMessagesVisible alarms. Free, 5-minute read-only scan.
Related Amazon SQS metrics
ApproximateNumberOfMessagesVisible rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon SQS coverage.
FAQ
Frequently asked questions about ApproximateNumberOfMessagesVisible
Common questions about setting up CloudWatch alarms for ApproximateNumberOfMessagesVisible in Amazon SQS.
What is the recommended CloudWatch alarm threshold for ApproximateNumberOfMessagesVisible?+
Sustained upward trend over 15+ minutes, evaluated with metric math against a rolling baseline rather than a fixed count. AWS does not publish a universal depth threshold because normal queue depth varies enormously by workload — a healthy batch-processing queue and a healthy real-time queue have very different baselines. A trend-based alarm (ConvOps recommendation) — depth still climbing after 15 minutes rather than a spike that recovers — distinguishes a genuine backlog from the normal sawtooth pattern of batch producers.
Which CloudWatch namespace does ApproximateNumberOfMessagesVisible belong to?+
ApproximateNumberOfMessagesVisible is published in the AWS/SQS namespace with a unit of Count. You can find it in the CloudWatch console under "Metrics" → "AWS/SQS". See the Amazon SQS CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for ApproximateNumberOfMessagesVisible?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Amazon SQS resources are missing a ApproximateNumberOfMessagesVisible alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a ApproximateNumberOfMessagesVisible alarm set up?+
Yes. The free Audit works whether or not you have any ApproximateNumberOfMessagesVisible alarm configured — it reads the resource directly from CloudWatch and tells you which resources need one, plus the copy-paste AWS CLI command to create it.
This page is part of the CloudWatch metric guide — thresholds and debugging guidance for every metric across RDS, Lambda, ECS, ALB, EC2, and DynamoDB. To find which Amazon SQS alarms your account is missing — including ApproximateNumberOfMessagesVisible — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.