Messages that fail on the network get retried, not lost

A retryable send failure is persisted with its original options and replayed on a backoff until it succeeds or is declared dead.

What it is

A durable outbox for sends that failed before reaching the provider. A scheduled drain claims due rows, replays the original send, backs off exponentially, and marks a permanently-failed row dead so it is visible for support and never retried again.

Also called: message didn't send · retry failed messages · network error sending

See it
Messages that fail on the network get retried, not lost
Area
Platform & Admin
Group
Sending
System
Customer Communications
Solves
3 named problems
01Rows are claimed with a compare-and-set on status so overlapping runs cannot double-send
02Rows stuck 'sending' for more than 15 minutes are reclaimed from a crashed run
03Backoff is 5 minutes × 2^attempts; rows die after six attempts
Diagram: failed send → outbox row → backoff retries → sent or dead. No primary screen. Sample data — no customer information appears here.
How it works
  1. 1Rows are claimed with a compare-and-set on status so overlapping runs cannot double-send
  2. 2Rows stuck 'sending' for more than 15 minutes are reclaimed from a crashed run
  3. 3Backoff is 5 minutes × 2^attempts; rows die after six attempts
  4. 4Replays carry a fromOutbox flag so a still-failing send updates the row instead of enqueuing a duplicate
  5. 5A send that comes back 'skipped' (the provider was unconfigured by the time we retried) is marked dead with the reason — retrying cannot fix configuration
Why we built it

A send that failed at the network level — where the request never reached the provider at all — used to disappear without a trace, so a customer simply never got their estimate notification and nobody could tell it had not gone. Those failures are now kept with everything needed to send them again and replayed on a backoff until they succeed or are declared dead. The alternative is a message that is silently lost and only discovered when the customer asks why they never heard back.

The problem
  • Sends lost to transient network failures
  • Duplicate sends from naive retry logic
  • Permanently failing messages retried forever
Sound familiar?
What you get
A hiccup costs a few minutes, not a message
Dead messages are visible instead of invisible
Overlapping drains cannot double-send

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →