How to Monitor AWS SNS Delivery Metrics and Failures

Amazon Simple Notification Service (SNS) is a fully managed pub/sub messaging service that powers everything from microservice event fans to SMS alerts and mobile push notifications. When SNS delivery silently fails, downstream services miss events and users never receive critical updates. AWS SNS monitoring with Amazon CloudWatch, delivery status logging, and dead-letter queues (DLQs) is what stands between silent failures and fast resolution.

This guide walks through every practical layer of SNS monitoring: the CloudWatch metrics that matter, how to configure delivery status logs, how to set up alarms, how to use DLQs, and how to troubleshoot the most common failure patterns. 

What Is AWS SNS Monitoring?

AWS SNS monitoring refers to the continuous collection and analysis of operational signals from SNS topics, subscriptions, and delivery attempts. The goal is to know, at any point, whether messages published to a topic are successfully reaching every subscriber, and if not, to understand exactly where and why delivery is breaking down.

Amazon SNS is integrated with Amazon CloudWatch by default. For every active SNS topic, AWS automatically collects and pushes a set of standard metrics to CloudWatch at 1-minute intervals. No additional configuration is required to start seeing these metrics. What does require configuration is delivery status logging, alarms, and dead-letter queues, which are the three tools that convert passive metric collection into actionable monitoring.

Core AWS SNS Metrics in CloudWatch

All SNS metrics live in the AWS/SNS namespace inside CloudWatch. They are available in the CloudWatch console under Metrics > All metrics > SNS, and can be segmented by topic name, phone number, SMS type, or country. Here are the metrics you must monitor.

Important note on NumberOfNotificationsFailed: SNS increments this counter only after the full delivery retry policy is exhausted. For SQS, email, SMS, and mobile push endpoints, AWS retries delivery before counting the failure. This means every unit in this metric represents a message that was permanently undelivered to at least one subscriber.

Important note on NumberOfNotificationsFilteredOut: Messages rejected by a subscription filter policy are not counted in NumberOfNotificationsFailed. They are intentional rejections. Monitor this metric separately to catch filter policy misconfigurations.

How to Access SNS Metrics in CloudWatch

Using the AWS Console

1. Open the CloudWatch console and choose Metrics in the left navigation.
2. In All metrics, select SNS.
3. Choose a dimension. Options include Topic Metrics (per topic), Country (SMS), SMS Type, PhoneNumber, and Metrics with no dimensions.
4. Select Topic Metrics, then choose NumberOfMessagesPublished to see the average number of messages published per minute over a 6-hour window.
5. To check account-level usage, go to All metrics > Usage > select a specific SNS usage metric such as NumberOfMessagesPublishedPerAccount.

Using the AWS CLI

To retrieve delivery failure statistics for a specific topic over the past hour:

aws cloudwatch get-metric-statistics \  --namespace AWS/SNS \  --metric-name NumberOfNotificationsFailed \  --dimensions Name=TopicName,Value=your-topic-name \  --start-time 2025-01-01T00:00:00Z \  --end-time 2025-01-01T01:00:00Z \  --period 3600 --statistics Sum

aws cloudwatch get-metric-statistics \  --namespace AWS/SNS \  --metric-name NumberOfNotificationsFailed \  --dimensions Name=TopicName,Value=your-topic-name \  --start-time 2025-01-01T00:00:00Z \  --end-time 2025-01-01T01:00:00Z \  --period 3600 --statistics Sum

How to Enable Delivery Status Logging

CloudWatch metrics tell you how many messages failed. Delivery status logging tells you which specific messages failed and what response the endpoint returned. Logs are written to CloudWatch Logs and must be enabled per topic and per protocol. 

Delivery status logs provide three key pieces of information:

• Whether a message was successfully delivered to an endpoint.
• The response returned by the endpoint to SNS.
• Message dwell time: the duration between the publish timestamp and the handoff to the endpoint.

Enable Delivery Logging via the Console

6. Open the Amazon SNS console and select your topic.
7. Choose Edit and expand the Delivery status logging section.
8. Choose the protocol to enable logging for: Amazon SQS, AWS Lambda, HTTP/S, or SMS.
9. Specify or create an IAM service role that grants SNS write access to CloudWatch Logs.
10. Set the success sampling rate. A rate of 100 logs every delivery attempt. A lower rate (for example, 10 or 1) logs a sample of successes while logging all failures.
11. Choose Save changes. Logs will appear in the CloudWatch Logs log group named sns/REGION/ACCOUNT-ID/TOPICNAME.

Enable SMS Delivery Logging via the Console

For SMS-specific delivery logs, the setup path is slightly different. Navigate to the Amazon SNS console, then Text messaging (SMS), then Mobile text messaging (SMS). Under Delivery status logs, specify the IAM role and sample rate. Note that SMS delivery logs can take up to 72 hours to appear in the SNS console, depending on the destination carrier.

Setting Up CloudWatch Alarms for SNS

Metrics are only useful when someone is alerted before failures accumulate. The following alarms represent a practical minimum for production SNS monitoring.

Alarm 1: Delivery Failures

This alarm fires when any delivery attempt to a subscriber fails after all retries. A threshold of 0 is appropriate for critical topics because any failure represents message loss.

resource "aws_cloudwatch_metric_alarm" "sns_delivery_failures" {  alarm_name          = "sns-delivery-failures"  comparison_operator = "GreaterThanThreshold"  evaluation_periods  = 2  metric_name         = "NumberOfNotificationsFailed"  namespace           = "AWS/SNS"  period              = 300  statistic           = "Sum"  threshold           = 0  alarm_description   = "SNS delivery failures detected"  alarm_actions       = [aws_sns_topic.alerts.arn]}

resource "aws_cloudwatch_metric_alarm" "sns_delivery_failures" {  alarm_name          = "sns-delivery-failures"  comparison_operator = "GreaterThanThreshold"  evaluation_periods  = 2  metric_name         = "NumberOfNotificationsFailed"  namespace           = "AWS/SNS"  period              = 300  statistic           = "Sum"  threshold           = 0  alarm_description   = "SNS delivery failures detected"  alarm_actions       = [aws_sns_topic.alerts.arn]}

Alarm 2: Drop in Publish Rate

If your application normally publishes 100 messages per minute and that rate drops to zero, something is broken upstream. This alarm detects an unexpected silence in message publishing, which is often the first sign of a producer-side failure.

aws cloudwatch put-metric-alarm \  --alarm-name sns-publish-rate-drop \  --metric-name NumberOfMessagesPublished \  --namespace AWS/SNS \  --dimensions Name=TopicName,Value=order-events \  --statistic Sum --period 300 \  --comparison-operator LessThanThreshold --threshold 1 \

aws cloudwatch put-metric-alarm \  --alarm-name sns-publish-rate-drop \  --metric-name NumberOfMessagesPublished \  --namespace AWS/SNS \  --dimensions Name=TopicName,Value=order-events \  --statistic Sum --period 300 \  --comparison-operator LessThanThreshold --threshold 1 \

Alarm 3: SMS Spend Approaching Quota

SMS spending in SNS is capped by a monthly quota. This alarm fires when cumulative spend reaches 80 percent of the quota, giving you time to request a limit increase before messages start failing.

aws cloudwatch put-metric-alarm \  --alarm-name SNSSpendingAlarm \  --metric-name SMSMonthToDateSpentUSD \  --namespace AWS/SNS \  --statistic Maximum --period 86400 \  --comparison-operator GreaterThanThreshold --threshold YOUR_QUOTA_TIMES_0.8

aws cloudwatch put-metric-alarm \  --alarm-name SNSSpendingAlarm \  --metric-name SMSMonthToDateSpentUSD \  --namespace AWS/SNS \  --statistic Maximum --period 86400 \  --comparison-operator GreaterThanThreshold --threshold YOUR_QUOTA_TIMES_0.8

Configuring Dead-Letter Queues for SNS

A dead-letter queue captures messages that SNS cannot deliver to a subscriber after exhausting the retry policy. Without a DLQ, those messages are permanently lost. With one, you can inspect what failed, fix the underlying issue, and replay the messages from the DLQ.

DLQs in SNS are configured at the subscription level, not at the topic level. Each subscription can have its own DLQ. The DLQ must be an Amazon SQS queue in the same AWS account and Region as the subscription. 

Enable a DLQ via the Console

12. Open the Amazon SNS console and choose Subscriptions in the navigation pane.
13. Select the subscription that needs a DLQ and choose Edit.
14. Expand the Redrive policy (dead-letter queue) section and enable the Redrive policy toggle.
15. Enter the Amazon Resource Name (ARN) of an existing SQS queue to use as your DLQ.
16. Choose Save changes.

Monitor the DLQ: Use the CloudWatch metric NumberOfNotificationsRedrivenToDlq to track how many messages are landing in DLQs. Set an alarm on this metric at threshold 0 for critical subscriptions. When it fires, inspect the DLQ messages for providerResponse details to understand why delivery failed repeatedly.

Troubleshooting AWS SNS Delivery Failures

When NumberOfNotificationsFailed or NumberOfNotificationsRedrivenToDlq increases, use this structured process to identify root causes.

Step-by-Step Troubleshooting Flow

17. Check NumberOfMessagesPublished. If this metric is zero or absent, the failure is upstream: the producer is not publishing to the topic. Investigate the application or service that calls sns:Publish.
18. Check NumberOfNotificationsDelivered and NumberOfNotificationsFailed. If published messages are not showing up as delivered or failed, check subscription states. A subscription in PendingConfirmation will not receive messages.
19. Check NumberOfNotificationsFilteredOut. If this metric has data, at least some messages are being rejected by subscription filter policies. Review whether message attributes match the filter policy on the affected subscription.
20. Enable delivery status logging. Open CloudWatch Logs for the topic log group and inspect the providerResponse field. For HTTP/S endpoints, non-2xx status codes identify application errors. For SQS, errors typically indicate IAM permission issues.
21. Check IAM policies. For SQS subscriber failures, verify that the SQS queue resource policy includes a statement allowing SNS to perform sqs:SendMessage on the queue ARN. Missing or overly restrictive policies are the most common cause of SNS-to-SQS delivery failure.
22. Check the DLQ. If a DLQ is configured, inspect messages in it for error metadata. The message attributes will include the reason SNS stopped retrying.

Common Failure Scenarios

Monitoring SNS Message Filtering with CloudWatch

SNS message filtering lets subscribers receive only the subset of messages that match their filter policy. When filters are misconfigured, messages are silently dropped and never reach their intended subscriber. CloudWatch exposes two metrics specifically for this: NumberOfNotificationsFilteredOut (rejected by filter policy) and NumberOfNotificationsDelivered (successfully passed through). 

To visualize filtering activity in the CloudWatch console:

23. Open the CloudWatch console and choose Metrics.
24. Select SNS > All Metrics > Topic Metrics.
25. Add NumberOfMessagesPublished, NumberOfNotificationsDelivered, and NumberOfNotificationsFilteredOut for the same topic to a single graph.
26. Set the time range. If the number of published messages consistently exceeds delivered plus failed, the gap is filtering.

CloudTrail Logging for SNS API Audit

AWS CloudTrail captures every API call made to Amazon SNS, including CreateTopic, Publish, Subscribe, Unsubscribe, and DeleteTopic. These logs are essential for security audits, compliance requirements, and understanding who made changes to topic configurations. 

CloudTrail SNS logs include:

• The identity that made the API call (user, role, or service).
• The source IP address and timestamp.
• The request parameters, including which topic was affected.
• The response returned by the SNS service.

CloudTrail management events for SNS are collected by default. Data events (individual Publish calls) are not collected by default because of their high volume and must be explicitly enabled in the CloudTrail console under Data events > SNS. Enable data event logging only if you need per-message audit trails, as it substantially increases CloudWatch Logs costs.

Building a CloudWatch Dashboard for SNS

A well-designed dashboard gives your team an at-a-glance view of SNS health across all critical topics. The following JSON structure creates a dashboard with the four most important widgets for production SNS monitoring.

{ "widgets": [  { "type": "metric", "properties": {    "title": "Messages Published (per minute)",    "metrics": [["AWS/SNS","NumberOfMessagesPublished",      "TopicName","order-events",{"stat":"Sum","period":60}]]  }},  { "type": "metric", "properties": {    "title": "Delivery Success vs Failures",    "metrics": [      ["AWS/SNS","NumberOfNotificationsDelivered","TopicName","order-events"],      ["AWS/SNS","NumberOfNotificationsFailed","TopicName","order-events"]    ]}}]}

{ "widgets": [  { "type": "metric", "properties": {    "title": "Messages Published (per minute)",    "metrics": [["AWS/SNS","NumberOfMessagesPublished",      "TopicName","order-events",{"stat":"Sum","period":60}]]  }},  { "type": "metric", "properties": {    "title": "Delivery Success vs Failures",    "metrics": [      ["AWS/SNS","NumberOfNotificationsDelivered","TopicName","order-events"],      ["AWS/SNS","NumberOfNotificationsFailed","TopicName","order-events"]    ]}}]}

SNS Monitoring Checklist for Production

Use this checklist when setting up or auditing SNS monitoring for any production workload.

Also Read

Disclaimer: The configurations, metric names, thresholds, and CLI examples in this article are for guidance only. Verify all details against the current AWS SNS documentation before applying to production environments. AWS service behavior, quotas, and metric definitions change over time. CubeAPM references reflect genuine use cases; evaluate all tools against your own requirements before adoption.

FAQs