Background jobs explained: how your SaaS sends 1,000 emails or generates a PDF report without freezing the screen — queues, retries, dead letter queues.
A background job is work your app does after answering the user: the app accepts the task, replies instantly, and a separate worker finishes the slow part behind the scenes. Sending 1,000 emails takes about five minutes. No user will stare at a frozen screen for five minutes — so production products never ask them to.
If your SaaS will ever send email in bulk, generate a report, or process an upload, you need this concept. Here's what it is, what belongs in a queue, and the mistakes that send your users five copies of the same email.
What is a background job, in plain language?
Think of a busy café. You order at the counter, pay, get a number, and sit down. The kitchen works through orders in sequence, and yours arrives when it's ready. Nobody stands at the till blocking the queue until their sandwich is toasted.
Without background jobs, that's exactly what your app does. A user clicks "send campaign", and the app grinds through 1,000 emails while the screen freezes — for five full minutes. With background jobs, the click just adds the task to a queue and instantly replies "campaign queued, will be sent shortly". A worker — a separate process whose whole job is working through the queue — sends the emails, retries the failures, and reports progress.
What belongs in a queue — and what doesn't
The rule of thumb: anything slower than a blink goes to the background.
| Task | Why the user can't wait for it |
|---|---|
| Sending an email campaign | 1,000 emails takes about 5 minutes |
| Generating a PDF report | Takes around 30 seconds |
| Processing a video upload | Takes around 10 minutes |
| A daily digest at 9am | Nobody is clicking a button at 9am — it's scheduled |
| Delivering data to another service | The other service might be down; the job retries later |
And what doesn't belong there: anything the user expects instantly. Loading a page, saving a form, logging in, taking a payment — these must happen in the moment. Queuing them adds delay for no benefit. This is the same pattern Stripe uses for invoice generation and email receipts, GitHub uses for its build pipelines, and Zapier uses for every automation it runs.
Retries, backoff, and the dead letter queue
Here's the real reason background jobs matter: failure handling. Jobs fail constantly in production — a mail provider hiccups, an API you depend on goes down, a server restarts mid-task. A good job system retries automatically, with growing delays between attempts: one minute, then five, then fifteen, then sixty.
Those growing delays — "exponential backoff" — matter more than they look. If a third-party service goes down and your jobs retry every minute for hours, you're hammering a dead server, and you can get your addresses banned for it. Backing off politely is how systems fail gracefully.
And when a job has failed too many times? It doesn't retry forever. It moves to the dead letter queue — a parking lot for jobs that need a human decision. You review them, fix the underlying problem, and re-run them with one click. Every job lives somewhere on one path: pending, processing, completed — or failed, retrying, and eventually dead-lettered.
The mistakes that send five copies of the same email
Background jobs are a solved pattern, but four classic mistakes keep biting founders who let AI build the system without knowing what to check:
- Jobs that aren't safe to repeat. A job sends an email, then crashes before recording that it finished. The retry runs — and sends the email again. The user receives five copies of the same message. Fix: before doing the work, the job checks "did I already do this?" Engineers call this idempotency; you can call it the no-duplicates rule.
- One job per email. A campaign to 10,000 users created as 10,000 separate jobs floods the queue and slows the whole database to a crawl. Batch instead: one job per 100 recipients turns 10,000 jobs into 100.
- No limit on simultaneous work. Fifty video-processing jobs running at once max out the machine and crash the server. Each queue needs a cap on how many jobs run at the same time.
- Jobs stuck in limbo. The server restarts mid-job and the job sits marked "processing" forever — no worker will touch it again. Fix: workers send a heartbeat every 30 seconds; any job with no pulse for 2 minutes goes back in the queue.
Scheduled tasks: the other half
Some work isn't triggered by a user at all — it's triggered by the clock. The daily digest at 9am. The weekly report. Monthly billing. Cleaning out old data. These are scheduled tasks: you define the timetable once, and the job system runs them automatically, with the same retry safety net as everything else. If the 9am digest fails, it retries — you don't find out a week later that nothing was sent.
Do you need this for your MVP?
If your MVP only does instant things — forms, pages, payments — skip it for now. But the moment you add your first email campaign, export, or upload processing, background jobs stop being optional. They're one of the 18 systems every SaaS eventually needs, and nearly half the others lean on this one: email, notifications, and reports all queue their heavy work here.
Two more things. First, a queue you can't see into is a queue that's silently on fire — pair it with monitoring you'll actually look at, so you know when the dead letter queue starts filling up. Second, this is very buildable with AI: from a complete specification, the whole system — queues, retries, the scheduler, the dashboard — takes around 3-4 hours with Claude. Your job is to test the failure paths, because the failure paths are the product.
Frequently asked questions
What is a background job in simple terms?
It's work your app does after replying to the user. Instead of making someone watch a frozen screen while 1,000 emails go out, the app queues the task, answers instantly, and a separate worker does the slow part — with automatic retries if anything fails.
What happens when a background job fails?
It retries automatically, with growing delays between attempts — one minute, then five, then fifteen, then sixty — so a struggling service isn't hammered. If it still fails after the maximum attempts, it moves to the dead letter queue, where you review it and re-run it once the underlying problem is fixed.
What is a dead letter queue?
A holding area for jobs that failed every retry. Nothing is lost and nothing retries pointlessly forever — the job waits there with its full history until a human decides what to do. An empty dead letter queue is one of the healthiest signals your product can show you.
Do I need background jobs for my MVP?
Only once you do something slow. Simple queries and instant actions don't need a queue — the overhead isn't worth it, and critical real-time operations like payments and login should never be queued. Add jobs when you add your first bulk email, report, or file processing feature.