GitHubSign inSign up

Open-source telemetry for clear skies across every queue.

Queue observability is hard. Trailbeam makes it easy, with the full history of every message passing through your queues.

Star on GitHub
  1. 0 s

    Sent by webhook-receiver

    Look up any message.

    Look up messages by message ID, tenant or a captured field. Each one opens with its full history, starting with the SendMessage call.

    SearchSample data
    9f3c2a71-5d2e-4c1e-b7a0-38e1d2f4a6c9
    Sent at
    14:02:07.112OpenTelemetry
    {  "type": "invoice.finalized",  "account": "acme-corp",  "invoice": {    "id": "in_1Q8Zf2…",    "amount_due": 48200,    "customer_email": redacted,    "customer_name": redacted  }}

    You choose which fields are redacted. Payload capture is off until you turn it on. What you capture is encrypted in transit and at rest.

  2. 64 ms

    Received, attempt 1

    See what your consumer did with it.

    Each receive is recorded with where it ran, what SQS reported about the message, and the spans from your handler.

    Attempt 1Trailbeam pkg

    The message

    Receive count
    1 of 3 allowed
    Time in queue before this receive
    64 ms
    Visibility timeout
    30 s until 14:02:37.176

    The consumer

    Consumer
    billing-sync version 41
    Request ID
    7a1f52c8-3e0b-4d6a-9f21…
    Position in batch
    1 of 4 messages
    Inside the consumerfunction timeout 10 s

    No DeleteMessage

    The consumer did not delete the message, so it becomes visible again at 14:02:37.176.

  3. 10.064 s

    No DeleteMessage

    Keep following after your trace ends.

    Your trace stops with the consumer. Trailbeam keeps following the message: it was not deleted, so it stays in flight until its visibility timeout expires, then becomes visible and is received again.

    After attempt 1
    First receive
    When a consumer first received the message. It is in flight from this moment, and the visibility timeout starts counting. Compare it with the send time to see how long the message sat in the queue.
    14:02:07.176
    Last span from the consumer
    The last thing recorded from the consumer on this receive. No DeleteMessage followed it, so the message stayed in the queue, not visible. This is where your trace ends, and where most tools lose the message.
    14:02:17.176
    Visible again
    First receive plus the queue's 30 s visibility timeout. SQS emits no event when it expires; the time follows from those two recorded values. It is the earliest a retry can happen.
    14:02:37.176
    Second receive
    When the message was received again, with receive count 2. The gap after it became visible is how long your consumers took to poll it.
    14:02:37.292
  4. 30.064 s

    Visibility timeout expired

    Count every retry and see where the time went.

    30.180 sReceived, attempt 2
    40.180 sNo DeleteMessage
    60.300 sReceived, attempt 3
    70.300 sNo DeleteMessage
  5. 90.420 s

    Moved to the dead-letter queue

    Know why it was dead-lettered.

    SQS doesn't log the move to a dead-letter queue. Trailbeam works it out from the receive count and the maxReceiveCount in your redrive policy, and shows the evidence it used.

    Get told when it happens.

    Trailbeam can notify your team as soon as a message is dead-lettered, a queue's throughput moves outside the range you set, or messages stay in flight too long. Each alert links to the queue and to the full history of every message involved.

    • Slack
    • PagerDuty
    • Zoom
    • Webhook

What other tools can't see

Ten things about one SQS message, across the tools you probably already run.

    • Trailbeam
    • Datadog
    • OpenTelemetry
    • AWS X-Ray
    • CloudWatch
    • Sentry
    • Trailbeam
    • Datadog
    • OpenTelemetry
    • AWS X-Ray
    • CloudWatch
    • Sentry
    • Trailbeam
    • Datadog
    • OpenTelemetry
    • AWS X-Ray
    • CloudWatch
    • Sentry
    • Trailbeam
    • Datadog
    • OpenTelemetry
    • AWS X-Ray
    • CloudWatch
    • Sentry
Sources and notes

Based on each vendor's public documentation as of November 2026.

OpenTelemetry: Trailbeam reads the OpenTelemetry you already run, so the two work together. This column compares what OpenTelemetry gives you on its own.

Datadog: compared with Datadog APM and Data Streams Monitoring for Amazon SQS. Datadog's message inspection covers Kafka only.

Three steps to your first trail.

  1. It works with the tracing you already run, and nothing else in your code changes.

    $ pip install trailbeam
    from opentelemetry.instrumentation.botocore import BotocoreInstrumentorimport trailbeam BotocoreInstrumentor().instrument()trailbeam.init(tenant_from="body.account") @trailbeam.sqs_handlerdef handler(event, context): ...

We watch from the mountain. We never touch your queue.

Trailbeam never calls ReceiveMessage on your queues.

The IAM role is read-only.

Payload capture is off by default. When it is on, contents are redacted and only admins can see them.