Monitoring

1. Key Metrics#

Metric	Meaning	Alert Hint
`ApproximateNumberOfMessagesVisible`	backlog waiting to be processed	sustained growth means consumer lag
`ApproximateNumberOfMessagesNotVisible`	in-flight messages	high value can mean slow workers or stuck deletes
`ApproximateAgeOfOldestMessage`	oldest visible message age	primary queue latency/SLO signal
`NumberOfMessagesSent`	producer volume	sudden drop/spike can indicate upstream issue
`NumberOfMessagesReceived`	consumer receive volume	compare with sent/deleted
`NumberOfMessagesDeleted`	messages deleted by consumers	success-ish signal, but duplicates can affect interpretation
DLQ `ApproximateNumberOfMessagesVisible`	failed messages waiting for triage	should normally be 0

2. Recommended Alarms#

source queue:
    ApproximateAgeOfOldestMessage > business SLO for 5 minutes
    ApproximateNumberOfMessagesVisible grows for 10 minutes
    ApproximateNumberOfMessagesNotVisible near in-flight limit
    NumberOfMessagesSent drops unexpectedly for critical event path

DLQ:
    ApproximateNumberOfMessagesVisible >= 1 for 1 datapoint

consumer:
    error rate > 1%
    processing latency p95 > visibility timeout / 2
    delete failure count > 0
    downstream dependency latency/errors

3. Incident Checklist#

queue age high:
    check consumer logs
    check worker replicas / concurrency
    check downstream database/API latency
    check visibility timeout and in-flight count
    scale carefully, do not overload downstream

DLQ has messages:
    sample message safely
    check ApproximateReceiveCount
    identify schema/version/business error
    fix consumer or data
    redrive small batch first

duplicates observed:
    verify idempotency key
    check visibility timeout too short
    check consumer deletes only after success
    standard queues can duplicate by design