Background Jobs at Scale: Inngest, Trigger, Cron, and Beyond

What you actually need to know

• Inngest and Trigger.dev have made durable execution a managed product.
• Use them for multi step work, scheduling, fan out, and long running flows.
• Use a simple queue for single step background work.
• Cron is still the right tool for known time scheduled jobs.
• The cost of these platforms is less than the operational tax of self hosting equivalents.

The core argument

Background jobs have evolved past the era when every team rolled their own Sidekiq or Celery setup. The modern serverless stack made the queue pattern awkward, because there is no long running worker to pull jobs. Inngest and Trigger.dev solved the problem by inverting the model. The runtime invokes your serverless functions when a job is ready. Your code runs in your own infrastructure. The orchestration lives in their platform.

The shift matters because most modern web stacks are serverless leaning. Next.js, Cloudflare Workers, Vercel Functions, AWS Lambda. The traditional queue with a long running worker does not fit cleanly. The managed durable executor does.

The pattern also enables work that was previously hard. A multi step process that runs over hours, with retries per step, with the ability to resume after a worker restart. Build it in raw Postgres and the code is brittle. Build it in Inngest or Trigger and the platform handles the state.

The cost of these platforms is real but it is less than the cost of building the equivalent in house. The break even is usually around the third multi step flow. The first flow you can build yourself. By the third one the platform is paying back in engineering time saved.

When to pick which

Inngest and Trigger are similar in shape. Both are JS first. Both invoke your serverless functions. Both handle scheduling, fan out, retries, and step state. The differences are at the margin. Inngest has the cleaner Next.js integration. Trigger has the longer history. Pick the one your team finds more pleasant.

Cron is the right tool when the schedule is the entire job. A nightly report. A weekly digest. A monthly billing run. The job is one step. The schedule is the thing. Cron or the scheduler in your queue handles this without ceremony.

AWS Step Functions is the right tool when you live deep in AWS and the workflow is mostly AWS service orchestration. It is powerful and operationally serious. Pick it if your team is already AWS first and your workflows are mostly invoking AWS services.

Temporal is the right tool for large engineering organizations with serious workflow requirements. The learning curve is real. The operational complexity is real. The payoff is durability and expressiveness past what the lighter options offer.

Features the durable execution platform must have

• Step level retries with exponential backoff.
• Idempotent step design as a first class concern.
• Scheduling support with timezone aware cron expressions.
• Fan out and fan in for parallel work.
• Observable execution history with replay.
• Concurrency limits per function and per resource.
• A clear local development story.
• A migration path to and from the platform.

Expert opinion

The durable execution platforms have collapsed a class of engineering work that used to take quarters into something you can adopt in a sprint. The teams that recognized this early shipped multi step features that their competitors are still building from scratch. The platform itself is now a competitive lever, not just an infrastructure choice.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A SaaS client wanted to add an onboarding sequence that ran across two weeks. Welcome email day zero. Setup reminder day three. Feature highlight day seven. Check in day fourteen. Each step depended on the customer's state at that point. The team had written the first version as a cron loop that queried the database every hour.

The cron loop worked for the first six months. At scale it started missing customers and duplicating sends. The team had spent three weeks trying to harden it.

We migrated to Inngest. The whole onboarding sequence became a single durable function with sleep statements between steps and conditional branches based on state. The code was shorter than the cron loop it replaced. The reliability problems vanished. The onboarding completion rate improved by roughly fifteen percent because the messages started landing reliably.

For more on the broader background work, see background job queues the architecture decision founders skip and why your SaaS should have a job queue from day one.

Common mistakes teams make

1. Building durable execution from scratch on Postgres. The cost outruns the platform fee.
2. Using a queue for multi step state. The retries duplicate previous steps.
3. Picking Temporal too early. The operational tax kills velocity for small teams.
4. Treating cron as the workflow engine. Cron is for known time scheduling.
5. No observability for the flow. The platform makes this free if you use it.
6. Non idempotent steps. Retries duplicate side effects.
7. Mixing dev and prod in the same platform tenant.
8. No migration plan. Lock in is real if you do not abstract.

A 30 day plan to adopt a durable execution platform

1. Week one. Inventory the multi step flows. Onboarding, billing, integrations, reports.
2. Week two. Pick the platform. Inngest or Trigger for most modern stacks.
3. Week three. Migrate the first flow. Make every step idempotent.
4. Week four. Migrate the rest. Add observability. Document the runbook.

For more on the related work, read Inngest vs Trigger vs Temporal for background jobs and workflow engines when you need Temporal when you need Cron. On the reliability side, async job failure recovery patterns that actually work is the natural next read.