What this is for#
If AcelleMail tried to push every email in a 50,000-recipient campaign at the same instant, three things would break:
- Your sender reputation — receiving servers treat a 50k spike as a spam pattern
- Your SMTP provider — every provider rate-limits sends per second / per minute; you'd be throttled or banned
- Your campaign itself — a single transient network blip would lose thousands of messages with no retry
So AcelleMail does the opposite: it converts the campaign into a queue of small jobs and lets background workers drain that queue at a sustainable pace. This guide explains the model, the four states a campaign passes through, and what to watch.
The campaign lifecycle, four statuses#
Every campaign you send moves through these statuses on the campaign Overview page. They tell you exactly where the campaign is.
| Status badge |
What's happening |
Typical duration |
| Draft |
You're still editing it — no jobs exist yet |
Until you click Send |
| Queuing |
AcelleMail is building the recipient queue — one job per subscriber |
Seconds (small list) to a minute or two (large list) |
| Queued |
All jobs exist, none have been picked up yet by a worker |
Brief — workers should pick up immediately |
| Sending |
Workers are draining the queue. Each completed job marks one recipient as delivered, soft-bounced, or hard-bounced |
Minutes to hours depending on list size + throttle rate |
| Done |
Every job has finished |
Final state — campaign report is now stable |
If your campaign sits on Queuing or Queued for more than a few minutes, your queue worker process isn't running — see the Common issues table below.
Why one job per recipient (not one big job)#
Splitting the work into per-recipient jobs is what gives AcelleMail two operational properties you want:
1. Retry is per-recipient. If recipient #4,237 fails because their mail server hiccupped, AcelleMail retries just that one job — it doesn't restart the whole campaign. The other 49,999 jobs are unaffected.
2. Pacing is automatic. You can run more or fewer workers, and the campaign automatically sends faster or slower without any UI change. Running 5 workers on a small VPS sends slowly and gently; running 50 workers on a tuned server sends faster — same code, same campaign, just more drains pulling from the same pool.
This is the same pattern Gmail itself uses internally. Big senders never blast — they pace.
The five job types you'll hear about#
You don't need to think about these — they're internals. But if you ever talk to an operator about your AcelleMail server's health, these are the names that come up:
| Job |
What it does |
| Campaign job |
Iterates the recipient list and dispatches a per-email job for each subscriber |
| Send-email job |
Sends one email to one recipient over SMTP |
| Bounce-processor job |
Reads incoming bounce notifications and updates subscriber statuses |
| Open / click tracker |
Records the events from the tracking pixel and link redirector |
| Webhook delivery job |
Pushes events to your configured webhook URLs |
Each runs independently. A backed-up open-tracking queue doesn't stop sends; a backed-up send queue doesn't stop tracking. They isolate failures.
What happens when a job fails#
Failed jobs are retried automatically — usually 3 attempts with a back-off (a delay between attempts that grows on each retry). A "soft" failure (recipient server busy, network timeout) almost always succeeds on retry 2 or 3. A "hard" failure (recipient address doesn't exist, domain has no MX record) is recorded as a bounce immediately and not retried.
After all retries are exhausted, the job lands in a failed jobs table. Your operator can re-dispatch it manually if needed, or inspect it to understand why a class of failure is recurring. From the marketer's side: any hard bounces become subscriber-status changes you can see on the list; failed jobs that didn't cause a bounce are an operator concern.
How to read send progress#
Open the campaign Overview while it's in Sending. The progress bar fills as the worker queue drains. The recipients counter (Delivered: 12,300 / 50,000) increments as each send-email job finishes.
The campaign report tabs (Opens, Clicks, Bounces, Unsubscribes) start populating as soon as the first events come in — even before the campaign moves to Done. So you can see early engagement signal while a long campaign is still finishing the send.
Common issues#
| What you see |
What to do |
| Campaign stuck on Queuing |
Your queue worker is not running. The operator command is supervisorctl restart acellemail-worker:* on most setups. See Setting Up Queue Workers and Cron Jobs. |
| Campaign on Sending for hours but delivery count barely moves |
Either: (a) your SMTP provider is rate-limiting you (check the provider dashboard), or (b) your queue worker count is too low. Talk to the operator. |
| Send completes but bounce count is stuck at 0 even though some addresses are invalid |
The bounce-processor job is not running — check the bounce-handler config under Bounce handlers in the admin sidebar. |
| Some recipients got the email twice |
Almost never the queue — usually the campaign was duplicated or a list contains the same address twice. Check Lists → [list] → Subscribers for duplicates. |
What to do after#
- Watch one of your next live campaigns through the status flow — Queuing → Queued → Sending → Done — to see the model in action.
- If your campaigns sit on Queuing longer than ~30 seconds, ask your operator whether queue workers + the cron scheduler are running.
- Pair this with How Email Delivery Actually Works for the receiving side.
Related articles#
