# Email Queue Architecture in AcelleMail (Why Sends Are Steady, Not Sudden)

> AcelleMail uses a job queue to pace out large sends — instead of trying to push 50,000 emails at once, workers pick recipients off a queue one at a time. This explainer covers why that matters for deliverability and how to read the campaign status flow.

- Canonical URL: https://acellesend.com/kb/articles/email-queue-architecture-in-acellemail
- Author: Lena Hart, Email Deliverability Editor
- Category: Email Infrastructure — Mail servers, MTA configuration, relay setup, IP management, monitoring
- Content type: guide · Difficulty: intermediate
- Tags: Acellemail
- Published: 2026-06-06 · Last updated: 2026-08-15
- Reading time: 5 min
- Publisher: AcelleMail Knowledge Base, https://acellesend.com/kb

---

## 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:

1. **Your sender reputation** — receiving servers treat a 50k spike as a spam pattern
2. **Your SMTP provider** — every provider rate-limits sends per second / per minute; you'd be throttled or banned
3. **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](https://acellesend.com/kb/articles/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

1. Watch one of your next live campaigns through the status flow — *Queuing → Queued → Sending → Done* — to see the model in action.
2. If your campaigns sit on *Queuing* longer than ~30 seconds, ask your operator whether queue workers + the cron scheduler are running.
3. Pair this with [How Email Delivery Actually Works](https://acellesend.com/kb/articles/how-email-delivery-actually-works) for the receiving side.

## Related articles

- [How Email Delivery Actually Works](https://acellesend.com/kb/articles/how-email-delivery-actually-works)
- [Setting Up Queue Workers and Cron Jobs](https://acellesend.com/kb/articles/setting-up-queue-workers-and-cron-jobs)
- [Email Throttling and Rate Limits Explained](https://acellesend.com/kb/articles/email-throttling-and-rate-limits-explained)
- [Bounce Types Deep Dive](https://acellesend.com/kb/articles/understanding-email-bounce-types)

---

## Related articles

- [How Email Delivery Actually Works (What Happens After You Click Send)](https://acellesend.com/kb/articles/how-email-delivery-actually-works): When you press Send Campaign in AcelleMail, your message travels through five stages before it lands in someone's inbox. Knowing each stage tells you exactly where to look when a campaign goes sideways — and why some recipients see the email and others don't.
- [Dedicated vs Shared Sending IP: Which to Pick](https://acellesend.com/kb/articles/dedicated-vs-shared-ip-address): AcelleMail sends through whatever sending server you connect, so the dedicated-vs-shared IP choice is really a choice about your sending provider. Here's how to decide, and where it lives in AcelleMail.
- [Choosing the Queue Driver: Database vs Redis vs SQS for AcelleMail](https://acellesend.com/kb/articles/choosing-the-queue-driver-database-vs-redis-vs-sqs-for-acellemail): AcelleMail ships with `QUEUE_CONNECTION=database` as the default — and that's the right choice for installations up to ~500k emails per day. Past that threshold, database-queue contention starts to dominate worker time, and switching to Redis or SQS produces a step-change in throughput. This guide walks the trade-offs, the threshold where each driver wins, the migration steps, the AUTOMATION_QUEUE_CONNECTION separation pattern, and the operational gotchas you only learn after the first 3am queue incident.
- [BIMI with VMC — Cost, Process, and Whether It's Worth It](https://acellesend.com/kb/articles/bimi-with-vmc-cost-walkthrough): VMC (Verified Mark Certificate) costs $1,500/yr per domain and takes 4-8 weeks to obtain. This guide walks the cost math, the trademark requirements, the alternative paths, and a decision framework for whether VMC is right for your sending program.
- [Building Your Email Marketing SaaS](https://acellesend.com/kb/articles/building-your-email-marketing-saas): The technology side of an AcelleMail SaaS is solved. The hard part is the business: who you sell to, how you price, how you reach them, and how you keep them. This guide is the GTM + pricing playbook — opinionated, market-tested patterns for launching an email-marketing SaaS on the AcelleMail stack.