Schedule icon
Consume icon
Script icon
Docker icon
If icon
SlackIncomingWebhook icon
Log icon
Return icon

AWS SQS Dead Letter Queue Replay Gate

Monitors AWS SQS Dead Letter Queues, samples unprocessable message payloads, and triggers operational alerts before message retention expiration.

Categories
CloudInfrastructure

In event-driven cloud architectures using Amazon Simple Queue Service (SQS), Dead Letter Queues (DLQs) act as safety buffers for messages that repeatedly fail consumer processing due to unhandled exceptions, schema shifts, or downstream timeout errors.

However, messages residing in a DLQ remain subject to standard SQS retention periods (typically 4 to 14 days). If operational teams are unaware of accumulating dead-letter messages, critical customer events, such as invoice generation, order confirmations, or account provisioning, are silently discarded when retention windows elapse.

This blueprint provides an automated sentinel that probes designated Amazon SQS Dead Letter Queues on a 30-minute schedule. It samples messages without dropping payloads, extracts failure context and payload previews, and posts structured triage notifications to Slack before data loss occurs.

How it works

  1. Scheduled Monitoring: The dlq_check_schedule trigger (io.kestra.plugin.core.trigger.Schedule) executes every 30 minutes.
  2. Message Sampling: The sample_dlq_messages task (io.kestra.plugin.aws.sqs.Consume) fetches a controlled batch of messages with a safety visibility timeout.
  3. Payload Inspection: The analyze_dead_letter_payloads task (io.kestra.plugin.scripts.python.Script) extracts message bodies and metadata attributes into dlq_triage_report.json.
  4. Condition Branching: The evaluate_backlog_condition flowable task (io.kestra.plugin.core.flow.If) evaluates whether unprocessable messages were identified.
  5. Slack Notification: If messages exist, alert_on_call_dlq_accumulation (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) dispatches a formatted incident card.
  6. Audit Manifest: The export_dlq_manifest task records queue health metadata for execution tracking.

What you get

  • Automated DLQ backlog monitoring preventing silent message loss from retention timeouts.
  • Safe batch sampling preserving message payloads in the queue for subsequent remediation.
  • Formatted Slack alerts with error previews, queue targets, and redrive recommendations.
  • JSON diagnostic artifacts capturing raw payload headers for debugging.

Who it is for

  • Cloud Engineers and DevOps teams operating AWS SQS-based event-driven pipelines.
  • Application Developers maintaining microservice consumers that process asynchronous workloads.
  • Reliability Engineers responsible for zero-data-loss SLAs.

Why orchestrate this with Kestra

Building custom Lambda pollers or CloudWatch metric alarms often requires configuring multiple IAM roles, Lambda deployment packages, and SNS topic subscriptions. Kestra replaces that complexity with a declarative workflow that combines native SQS consumption, Docker-isolated Python inspection, and rich Slack integrations with zero infrastructure maintenance.

Inputs

Name Type Default Description
dlq_url STRING https://sqs.us-east-1.amazonaws.com/... Amazon SQS Dead Letter Queue URL to monitor.
target_queue_url STRING https://sqs.us-east-1.amazonaws.com/... Primary queue where redriven messages should land.
aws_region STRING us-east-1 AWS region hosting the queues.
max_messages_to_inspect INT 10 Maximum messages sampled per cycle.
slack_channel STRING #ops-alerts Slack channel destination for alerts.

Expected outputs

  • {{ outputs.analyze_dead_letter_payloads.vars.backlog_detected }}: Boolean flag indicating if messages were present.
  • {{ outputs.analyze_dead_letter_payloads.vars.message_count }}: Number of messages sampled.
  • {{ outputs.analyze_dead_letter_payloads.vars.sample_preview }}: Text snippet of the first sampled message payload.
  • {{ outputs.analyze_dead_letter_payloads.outputFiles['dlq_triage_report.json'] }}: Complete JSON diagnostic report.

Prerequisites

  • AWS IAM user or role with permissions: sqs:ReceiveMessage, sqs:GetQueueAttributes.
  • AWS credentials configured in Kestra secrets.
  • Slack Incoming Webhook configured for operational notifications.

Secrets

  • AWS_ACCESS_KEY_ID: AWS IAM access key ID.
  • AWS_SECRET_ACCESS_KEY: AWS IAM secret access key.
  • SLACK_WEBHOOK_URL: Slack Incoming Webhook endpoint URL.

Quick start

  1. Configure AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and SLACK_WEBHOOK_URL in your Kestra namespace secrets.
  2. Import this flow YAML into your Kestra instance.
  3. Click Execute in the UI to run an initial DLQ sampling check.
  4. Review execution outputs and Slack channels for verification.

Common pitfalls and troubleshooting

  • Visibility Timeout: Setting visibilityTimeout too low may cause sampled messages to become visible to concurrent consumers immediately; 30 seconds provides sufficient buffer for inspection.
  • FIFO Queues: Standard SQS queues use random sampling; FIFO queues strictly preserve message ordering and require Message Deduplication IDs when redriving.
  • Retention Window: SQS default retention is 4 days; verify your queue retention settings allow sufficient time for engineer intervention.

How to extend

  • Add an automated redrive task using io.kestra.plugin.aws.sqs.Produce to automatically replay sanitized messages back to target_queue_url.
  • Integrate with Jira via io.kestra.plugin.jira.CreateIssue to track recurring poison-pill messages in sprint backlogs.
  • Filter messages by specific error exception codes before redriving.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.