is a dead letter queue overkill for a side project doing 200 jobs a day Dead Letter

Mostly copying a diagram, but the discomfort is correct and worth acting on.

A dead letter queue gives you two things: somewhere failed messages land instead of vanishing, and a mechanism to replay them. At 200 a day you need the first and you can do the second by hand.

A failed_jobs table with payload, error, attempt count and replayed_at gets you there in about thirty lines, and you can query it, join it to the customer, and put it on a page - none of which a platform DLQ lets you do comfortably.

The thing people actually get wrong: a DLQ is not an alert. Messages arrive silently and sit there for months. Whatever you build, the part that matters is that something tells you.

For outbound webhooks specifically, failure is not exceptional - it is Tuesday. Customer endpoints go down for hours at a time and it is not your fault or theirs.

What you want:

• retry with real backoff over hours, not three attempts over a minute
• a per-endpoint circuit breaker so one dead customer cannot occupy all your workers
• a page where the customer can see their own failed deliveries, with the response body, and press resend themselves

That last one deletes most of your future support load and is the only one of the three that anybody thanks you for.

The log line is completely fine right up to the day you need to know which six of two hundred failed and your retention expired on Thursday.

If your platform gives you a dead letter queue for three lines of config, take it - the cost is near zero and failed messages stop being log lines with a seven day life. Just wire the alert on non-empty at the same time, and go and look at it weekly until you trust it.

Store the response body from their endpoint, truncated. "It failed" starts an investigation. "It returned 413 with a body about payload size" ends the conversation in one email.