Durable Email Send Jobs in Mailbase

Overview

Mailbase campaign fan-out now runs through durable send jobs. Launching or executing a scheduled campaign creates a job with recipient-level items, then the internal worker claims batches, records provider outcomes, retries transient failures, and exposes progress in the app.

Job model

Each send job tracks totals for queued, running, sent, skipped, retrying, failed, and cancelled recipients. The worker claims batches with transaction-safe locking so two worker runs do not send the same recipient at the same time.

Recipient-level job items store attempts, provider errors, retry timestamps, and final status. This gives operators a real failed-recipient view instead of a single vague campaign failure.

• Durable send_jobs and send_job_items records
• Batch claiming with safe locks
• Exponential retries for transient failures
• Provider error storage
• Failed-recipient dead-letter review

Runtime controls

Operators can pause, resume, or cancel an active campaign send. Workspace concurrency limits and provider rate-limit backoff keep the worker from overwhelming the delivery path.

The campaign detail page shows job progress and failed recipients, while server logs record job and webhook activity with redacted metadata.

• Pause, resume, and cancel
• Workspace concurrency limits
• Provider rate-limit backoff
• Progress UI
• Redacted operational logs

Common mistakes

• Choosing a tool before deciding who owns deliverability.
• Treating DNS authentication as a one-time checkbox instead of an operating baseline.
• Mixing product-critical transactional email with experimental marketing sends, with no clear boundary.
• Trusting headline metrics (like open rate) that privacy proxies now inflate.

Sources and further reading

Official docs for current setup details, pricing, and API behavior — verify specifics there, since they change.

Related guides

More on durable email send jobs and the surrounding product workflow: