Short answer: For an edtech weekly digest, retry only transient failures, use capped exponential backoff with jitter, and quarantine exhausted or invalid work in a dead-letter queue (DLQ). The durable boundary is an idempotency record: a repeated webhook or a worker crash must not send the same digest or publish the same processed image twice.

I've been paged for both missed jobs and duplicate deliveries. That is the trade-off I would make after seeing how quickly an ambiguous retry becomes a customer-facing incident. A queue can deliver a message again; it cannot know whether the side effect behind that message is safe to repeat. The application has to make that decision before it acknowledges the delivery.

How should a Node.js queue retry failed image webhooks?

Start by separating three events that are often treated as one: accepting a webhook, publishing a job, and completing the business action.…