Weekday morning Amazon SQS queue health digest in Slack
Every weekday at 8am, scan every Amazon SQS queue in your region, flag the ones backing up or filling a dead-letter queue, and post a grouped digest to Slack.
Every weekday at 8am, run a morning Amazon SQS health digest and post it to a Slack channel the user picks at setup. The trigger is a cron schedule the user can adjust (day of week, hour, timezone).
Start by calling Amazon SQS List Queues to enumerate every queue in the configured AWS region. If a queue-name prefix is provided at setup, pass it as the filter; otherwise list everything in the region.
For each queue URL returned, call Amazon SQS Get Queue Attributes and read ApproximateNumberOfMessages (visible backlog), ApproximateNumberOfMessagesNotVisible (in-flight messages consumers are working on), ApproximateAgeOfOldestMessage (how long the oldest message has been waiting), and RedrivePolicy (whether the queue targets a dead-letter queue). Use RedrivePolicy together with the queue name to tell whether the queue is itself a dead-letter queue or has one configured downstream.
Classify each queue as healthy, backing up, or DLQ-populated. A queue is DLQ-populated when it looks like a dead-letter queue (name suffix like -dlq or -deadletter, or it is referenced as the deadLetterTargetArn in another queue's RedrivePolicy) and it currently has any messages in it. A queue is backing up when its visible message count or its oldest-message age crosses a threshold the user can tune (defaults: more than 1,000 visible messages, or an oldest message older than 15 minutes). Everything else is healthy.
Rank the concerning queues first: DLQ-populated queues at the top, then backing-up queues sorted by oldest-message age descending. Group healthy queues into a single compact roll-up at the end so on-call sees the concerning items immediately.
Post one grouped digest to the chosen Slack channel using Slack Send a Message. Use clear severity emoji at the start of each line (🚨 for DLQ-populated, ⚠️ for backing up, ✅ for the healthy roll-up), and for each concerning queue show the queue name, visible message count, in-flight count, and the age of the oldest message. Underneath each hot queue add one short plain-English sentence explaining what those numbers mean so an on-call engineer can act fast — for example, ‘12,400 messages waiting and the oldest is 42 minutes old, so consumers are draining slower than producers are publishing’, or ‘423 messages sitting in the dead-letter queue, meaning downstream processing has been failing repeatedly and needs investigation before retention expires’.
If List Queues returns no queues at all, still post a single friendly note to the Slack channel saying no queues were found in the region so silence is never ambiguous.
Additional information
What does this prompt do?
- Reads every Amazon SQS queue in your region on a weekday schedule and pulls each one's current backlog, in-flight load, and age of the oldest message.
- Sorts queues by severity so the ones piling messages into a dead-letter queue or draining too slowly sit at the top of the digest.
- Posts one grouped Slack message with severity emoji, queue names, message counts, and a short plain-English note on each hot queue so on-call can act fast.
What do I need to use this?
- An AWS account with an access key that can list queues and read queue attributes in the region you want to cover.
- A Slack workspace and the channel where the morning digest should land.
How can I customize it?
- Change the time of day, weekdays, or timezone the digest runs on.
- Pick which Slack channel receives the digest, or switch to a private on-call channel if it is sensitive.
- Tune what counts as backing up by adjusting the message-count and oldest-message-age thresholds.
FAQs
Does this cover every queue automatically?
How does it handle dead-letter queues?
Can I use it across multiple AWS regions?
Will it post on weekends?
Can the digest go somewhere other than Slack?
Related templates
Every weekday morning, an agent reviews your open Dynamics 365 pipeline and privately DMs each rep only the deals that need attention today.
Every hour we compare the 30 minutes before and after each release, and only speak up when a deployment genuinely degraded speed or reliability.
Every weekday morning, every account balance is logged to a spreadsheet, and you only hear about it in Slack when one drops below the limit you set.
After every recorded sales call, an agent updates the right deal in Dynamics 365 and posts a Slack recap of exactly what changed.
Every contact sales form submission lands in Dynamics 365 as a clean lead, updating the record you already have instead of creating a second one.
Every New Relic alert opens a Jira bug with the full context and a Slack heads up, then closes itself with the incident duration when it recovers.
Stop refreshing the SQS console every morning.
Get a plain-English queue health digest waiting in Slack before your first coffee.