Weekly SQS dead-letter queue triage into Linear

Every Monday at 9am (user-configurable), triage our Amazon SQS dead-letter queue and file grouped Linear issues so the engineering team starts the week with a clear failure backlog. This is a peek pattern only: nothing gets deleted from SQS, because operators still need to be able to redrive.

Trigger: cron, weekly, Monday 9am, in the user's local timezone. Let the operator change the schedule when they configure the workflow.

Step 1 — Sample the dead-letter queue. Call Amazon SQS Receive Message against the configured DLQ URL with MaxNumberOfMessages set to 10, WaitTimeSeconds set high enough for long polling (up to 20), and VisibilityTimeout kept short (a few seconds) so messages become visible again quickly and stay available for redrive. Repeat the call for a handful of pages (roughly 5 to 10) to build a representative sample. Do NOT call DeleteMessage. Do NOT call ChangeMessageVisibility to hold messages longer. If the queue is empty across the sample, exit cleanly with a note that there was nothing to triage this week.

Step 2 — Parse and cluster. For each message returned, parse the message body (typically JSON, but be resilient to plain text). Cluster the sample by root cause signal: normalized error type or exception class, failing endpoint or handler name, the top frame of any stack trace, and repeating entity id patterns (for example the same customer id or job id showing up across many messages). Prefer clustering by the strongest signal and fall back to weaker ones. Keep a count per cluster and a representative sample payload for each.

Step 3 — Check Linear before filing. For each cluster, call Linear Search Issues using the cluster's key signal (error type + endpoint, or a distinctive substring) to find any open issue that already covers this pattern. If a matching open issue exists, skip creation for that cluster and note it in the run summary.

Step 4 — File genuinely new patterns. For each cluster with no existing open issue, call Linear Create Issue in the configured team. Write a readable title (for example: 'DLQ: TimeoutError in POST /invoices/sync — 42 msgs this week'). In the description include: a plain-English summary of the root cause, the count seen this week, the fields that defined the cluster, one representative payload (JSON code block, redact obvious secrets), and a suggested priority based on volume and error type. Map priority to Linear's numeric scale (1 Urgent, 2 High, 3 Normal, 4 Low). Apply a 'dlq-triage' label if the team uses labels.

Output: a short run summary listing clusters found, clusters skipped as duplicates (with existing issue URLs), and Linear issues newly created (with URLs). Never delete or purge SQS messages — the goal is visibility so operators can still call StartMessageMoveTask (redrive) when they are ready.