Background Jobs for a Modern SaaS, Without a DevOps Team

Every SaaS eventually needs to run something outside a normal HTTP request. Sending emails. Processing a webhook. Generating a report. Running an AI workflow that takes three minutes. The moment that first job needs to be async, a bunch of quiet decisions come due — and most teams get one or two of them wrong.

At Augere Labs we ship on modern serverless stacks (TanStack Start, Next.js, Cloudflare Workers, Supabase) where the old "just run a worker process" answer doesn't apply. Here's how we actually pick.

Why this is harder than it used to be

In a traditional VM setup, you spin up a Redis instance, add Sidekiq or Bull, and you're done. On Cloudflare Workers or Vercel edge functions, that pattern breaks — workers time out at 30–60 seconds, no long-lived connections, no cron in the framework.

AI features make this worse. A single agent call can take 45 seconds; a long generation can take three minutes; a batch job can take an hour. Trying to force that into an HTTP request is how you learn what a 504 gateway timeout looks like at 2am.

The three problems people conflate

Fire-and-forget

"After sign-up, send a welcome email." You don't need a queue. You need any way to run something after the response ships. On modern serverless, this is usually a background function or an event trigger.

Retryable async work

"Charge this card, then send a receipt." Multi-step, may fail, needs retries with exponential backoff, must not double-charge. This is where a real background job system earns its keep.

Scheduled / long-running work

"Every night, generate reports for each customer." Cron plus workers that can run for minutes. Different problem from the two above.

Picking the wrong tool for the right problem is a top-three mistake we see. Cron doesn't replace queues, and queues don't replace cron.

The current shortlist

Inngest

Currently our default for TanStack and Next.js SaaS. Function-based, event-driven, deep retry and step logic. You write TypeScript, define events, and Inngest handles queuing, retries, and observability. Free tier is generous; pricing kicks in around real scale.

Trigger.dev

Very similar shape to Inngest. Strong on developer experience and long-running task support. Both are viable — the choice often comes down to which dashboard your team prefers.

Upstash QStash

Simpler. Serverless message queue that POSTs to your HTTP endpoints. Good for teams that want the queue primitive without the framework. Cheap.

Cloudflare Queues + Workers

If you're already on Cloudflare, this integrates cleanly. Workers still have runtime limits, but the queue integration is solid. Use Cloudflare Workflows for step-based long jobs.

Supabase pg_cron + pg_boss / edge functions

If you're on Supabase and don't want another vendor, pg_cron for scheduling plus edge functions for the actual work covers a lot. Not as feature-rich as Inngest, but zero extra bill.

Traditional (BullMQ, Sidekiq, Celery)

Still the right answer if you're on a VM stack. Overkill and painful on serverless.

How we pick

Are you already on managed infra with cron and long timeouts?

If you're on Fly, Render, Railway with real containers, use whatever your language ecosystem gives you (BullMQ for Node, Sidekiq for Rails). Modern serverless queue services add cost you don't need.

Are you running any workflow over 60 seconds?

If yes, and you're on serverless, you need one of Inngest, Trigger.dev, Cloudflare Workflows, or a container fallback. HTTP background functions won't cut it.

Do you need step-based durability?

AI workflows often chain steps: fetch data, embed it, generate a summary, save to DB, send a notification. If step 4 fails, you want to retry from step 4, not from scratch. Inngest and Trigger.dev handle this natively. Simple queues don't.

Do you need multi-tenant isolation on jobs?

Every serious job system supports tagging. Use it. Tenant ID on every job so you can pause, cancel, or debug per customer.

Mistakes teams make

Running long AI workflows inside HTTP requests

The most common mistake. Works fine in local dev, times out in production. Move any operation over 20 seconds into a job from the start.

Using cron for what a queue should do

"Every minute, check if there are pending emails, and send them." That's a queue with extra steps. Trigger the send on the event, not on a schedule.

Ignoring idempotency

Retries mean the same job can run twice. If the job charges money, sends a message, or creates a resource, add an idempotency key. This is table stakes and shockingly often skipped.

No dead-letter queue

Some jobs will fail permanently. Without a dead-letter queue, they either retry forever (expensive) or vanish silently (worse). Every real system needs a bucket for jobs that gave up.

Building the "job system" in-house

"We'll just poll a database table." This works for the first five jobs. By fifty, you've reinvented a job queue badly. Buy the queue, build the business logic.

The AI workflow pattern

For AI features, the pattern we reach for repeatedly:

1. User triggers an action.
2. API creates a job and returns immediately with a job ID.
3. Frontend polls or subscribes to job status.
4. Background job runs the LLM calls, retries, and writes results.
5. Frontend receives completion event and renders.

This works for generations, agent runs, batch operations, and anything else that outlives an HTTP round trip. It's boring, and boring is the point.

Real example

A document-processing SaaS we worked with had users uploading PDFs that got summarized by an LLM. Original architecture: upload → HTTP request → LLM call → response. Worked fine at low volume. At scale, timeouts started firing on PDFs over 20 pages.

Migration to Inngest took about a week. Upload now creates a job, user sees a progress bar, LLM chain runs in the background with per-step retries. Timeout complaints went to zero. Support tickets from confused users ("did it work?") also dropped, because the progress state was now visible.

Trade-offs

Adding a job system introduces state: pending, running, succeeded, failed. Your UI needs to show it, your API needs to expose it, your monitoring needs to alert on it. This is real work.

The alternative — running everything inline — falls apart the moment a workflow crosses your platform's timeout. Front-load the complexity when adding the first async feature; it's cheaper than retrofitting later.

Common misconceptions

"Queues are only for high scale." No. Queues are for reliability. A 100-user SaaS still benefits from retries and durable job state.

"Serverless can't do long-running jobs." It can, with the right tool. Inngest, Trigger.dev, and Cloudflare Workflows are literally built for this.

"We can wait until we have a problem." The moment you have the problem — usually the first customer report about a stuck job — is the worst time to design the system. Design early, use the queue whenever an operation could plausibly exceed 20 seconds.

Frequently Asked Questions

Do I need a queue if I'm just sending emails?
Not necessarily. A background function or a lightweight scheduled trigger covers fire-and-forget. Add a queue when you need retries or step-based workflows.

Inngest vs Trigger.dev — which is better?
Both are excellent. Pick based on which dashboard and pricing model your team prefers. The engineering shape is very similar.

Can I run background jobs on Vercel?
Vercel Cron and Vercel Background Functions cover basics. For long-running or step-based work, add Inngest or Trigger.dev on top.

How do I test background jobs?
Use the local dev server your queue provider offers (Inngest and Trigger both have them). Unit-test the handler function separately.

Where to go next

For the broader stack picture, pair this with Vercel vs Cloudflare Workers. For AI-specific workflow patterns, building AI agents for business covers what the jobs actually do.

Working with us

Async infrastructure is one of those things every SaaS needs and few founders enjoy setting up. We handle this on almost every project — happy to talk through what fits your stack.