Background queues have a dead-letter or error-handling path

Background job queues without a dead-letter path are silent failure sinks: a job that consistently fails disappears from the active queue after its retry cap is exhausted, leaving no record of what went wrong unless you explicitly configure failure handling. For payment-adjacent jobs — subscription renewals, fulfillment triggers, invoice generation — silent failure means lost revenue and customer confusion. Even for non-financial jobs, the absence of a failure path makes debugging a production incident nearly impossible: you know something is wrong because users report it, but the queue gives you no evidence. The observability gap is the core risk, not the job failure itself.

Add a failed event handler to every Worker and route failures to your alerting stack. In src/lib/worker.ts or wherever workers are initialized:

import * as Sentry from '@sentry/node'

const worker = new Worker('payments', async (job) => {
  // ... job processor
})

worker.on('failed', (job, err) => {
  console.error(`[queue] Job ${job?.id} (${job?.name}) failed after ${job?.attemptsMade} attempts:`, err)
  Sentry.captureException(err, { extra: { jobId: job?.id, jobName: job?.name } })
})

worker.on('error', (err) => {
  Sentry.captureException(err)
})

Set removeOnFail: { count: 500 } to keep the last 500 failed jobs in Redis for post-mortem inspection without unbounded storage growth.