Amazon SQS queue health board for your on-call rotation

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.