# Amazon SQS queue health board for your on-call rotation

> See every message queue on one screen with live backlog, oldest message age and dead-letter depth, sorted worst first with trends and fixes built in.

- Workflow type: app
- Services: Amazon SQS, Amazon CloudWatch, Linear
- Categories: Engineering, Operations
- Published: 2026-08-14

## What it does

- Puts every queue on one screen: how many messages are waiting, how many are being worked on right now, how long the oldest message has been sitting there, and how deep its dead-letter backlog is.
- Sorts the worst queues to the top and flags the patterns that matter, including messages older than the queue's own processing window, queues running with no dead-letter safety net, and queues with no owner tag.
- Shows the owning team next to every queue, read from your existing queue tags, and marks untagged queues as owner unknown so ownership gaps are visible instead of quietly ignored.
- Click any queue for 24 hour and 7 day trend charts, then raise a prefilled issue or adjust its timeout and retention settings right there, behind a confirmation step.

## What you'll need

- An AWS account with access keys that can read your queues and their tags, plus permission to change queue settings if you want the inline edits.
- Read access to your AWS monitoring data, which is where the 24 hour and 7 day trend charts come from.
- A Linear workspace, if you want the raise-an-issue button. The board and charts work fine without it.
- Your queues tagged with a team or owner tag, if you want the ownership column filled in. Untagged queues still appear, marked owner unknown.

## Prompt

I want a queue fleet health board for Amazon SQS that our on-call rotation opens every morning and again during incidents. The whole point of this surface is the fleet view with ownership attached, because the AWS console makes you click into one queue at a time and never tells you who owns it.

The main screen is one row per queue. Load the queue list with the Amazon SQS List Queues operation, which accepts a queue name prefix filter. Note that List Queues only paginates when a maximum result count is set, so request pages explicitly and follow the next token until the list is complete. For every queue, call Get Queue Attributes and read ApproximateNumberOfMessages for the live backlog, ApproximateNumberOfMessagesNotVisible for the in-flight count, ApproximateAgeOfOldestMessage for the age of the oldest waiting message, plus VisibilityTimeout, MessageRetentionPeriod, RedrivePolicy and QueueArn. Fan these calls out concurrently with a sensible concurrency cap so a fleet of a hundred queues still loads quickly.

Read the owning team from List Queue Tags on each queue. Look for a team-style tag key such as Team, team, Owner or owner, and use the first one present.

The RedrivePolicy attribute is what tells you whether a dead-letter queue is configured and which queue it points at. Parse its deadLetterTargetArn, turn that ARN into the target queue name, and make a second Get Queue Attributes call against the dead-letter queue to fill the dead-letter depth column. Cache those lookups within a single refresh so a shared dead-letter queue is not fetched once per source queue.

Columns: queue name, owning team, backlog, in flight, age of oldest message, dead-letter depth, and a status badge. Three rules drive that badge, and they matter more than the raw numbers. First, flag any queue whose oldest message is older than its own visibility timeout, because that means messages are being redelivered rather than processed. Compare against that queue's own VisibilityTimeout value, never a fixed number. Second, treat a queue with no dead-letter queue configured as a warning row rather than a healthy one, with the dead-letter column reading Not configured. Third, show untagged queues as Owner unknown so ownership gaps are visible on the board instead of silently ignored.

Sort worst first by default: queues breaching their own visibility timeout at the top, then anything with a non-empty dead-letter queue, then descending oldest-message age, then descending backlog. Keep every column clickable for manual sorting. Give the board a team filter built from the tags actually found, including an Owner unknown option, and a queue name prefix filter that is passed through to List Queues so it narrows the fetch rather than only the rendered rows. Show a last refreshed timestamp and a manual refresh button, because these ages and depths are only as fresh as the last load and the user needs to know that during an incident.

Clicking a queue opens a detail view. The header repeats the live numbers and the current configuration: visibility timeout, message retention period, and the dead-letter queue name if one is set.

Below the header, chart the last 24 hours and the last 7 days using the Amazon CloudWatch Get Metric Statistics operation against the AWS/SQS namespace with the QueueName dimension. Chart ApproximateNumberOfMessagesVisible for backlog and ApproximateAgeOfOldestMessage for oldest-message age, using a five minute period for the 24 hour range and a one hour period for the 7 day range, with the Maximum statistic. These charts exist for one specific judgement: telling a one-off spike from a steady climb before deciding anything, so put the two ranges side by side or behind a clear toggle. Message ages come back in seconds, so render them as readable durations like 3h 12m, and say so plainly when CloudWatch returns no datapoints for a range instead of drawing an empty chart.

From the detail view the user can raise a Linear issue with Create Issue, prefilled and still editable. The title carries the queue name and the headline number, and the description carries the current backlog, in-flight count, oldest message age, dead-letter depth, visibility timeout and a link back to this queue's detail view on the board. Let the user pick the Linear team from a list loaded with List Teams, defaulting to whichever team they chose last time. Once created, show the issue identifier and a link to it rather than a bare success message.

Also from the detail view, let the user adjust the visibility timeout or the message retention period inline with Set Queue Attributes, behind a confirmation step that spells out the queue name and both the old and new values before anything is written. Validate against the AWS ranges first (visibility timeout 0 to 43200 seconds, message retention 60 to 1209600 seconds), and re-read the queue with Get Queue Attributes after a successful write so the screen shows the committed state rather than the value that was typed.

Persist a small change log: every configuration change made through the app, with the queue, the attribute, the old and new values, who made it and when, surfaced on that queue's detail view. During an incident the first question is usually whether someone already changed something. Also remember each user's last used filters and their preferred Linear team so the board opens where they left it.

Two operational details. An AWS connection covers a single region, so name the region on the board. And if one queue's attribute or tag call fails, render that row with an error marker and keep the rest of the board working rather than failing the entire screen.

## How to customize

- Change what counts as unhealthy. Out of the box the board compares each queue's oldest message against that queue's own processing window, and you can layer your own backlog or age thresholds on top.
- Swap the tag the ownership column reads if your team labels queues with something other than Team or Owner.
- Adjust the chart ranges, for example a 1 hour view during a live incident or a 30 day view for capacity planning.
- Change what gets prefilled into the issue, or point the button at a different team in your tracker.

## FAQ

### Does opening the board change anything in my AWS account?

No. Loading and refreshing the board only reads your queues, their tags and your monitoring history. The only two things that write anything are the raise-an-issue button and the settings edit, and both sit behind an explicit confirmation step.

### Will it show queues from more than one AWS region?

Each AWS connection covers a single region, so the board shows that region's queues and names the region on screen. If you run queues in several regions, add a connection for each one.

### What happens to queues that are not tagged with a team?

They still appear on the board, marked owner unknown, so the gap is visible rather than hidden. You can filter the board down to just those rows when you want to clean up your tagging.

### Why is a queue with no dead-letter queue shown as a warning?

Because a queue with no dead-letter queue has nowhere to put messages that keep failing, so bad messages retry forever and quietly hold up everything behind them. The board treats that as something to look at rather than as healthy.

### How current are the numbers on the board?

They are fetched when you open or refresh the board, and the screen shows exactly when it last refreshed so you are never guessing during an incident. The trend charts come from your stored AWS monitoring history.

### Do I need a Linear account to use this?

Only for the button that raises an issue from a queue's detail view. Everything else, including the fleet board, the filters and the trend charts, works without it.

Use this prompt in General Input: https://www.generalinput.com/prompts/amazon-sqs-queue-health-board-for-your-on-call-rotation