Inngest for Background Jobs: How to Decide

Inngest treats background work as events rather than as a queue, and that single decision is what you are choosing for or against. What it buys you, what it costs, and the workloads where something else fits better.

What the model buys you

Step durability. This is the feature that matters. Each step in a function is durably checkpointed, so a function that fails at step 5 of 12 restarts at step 5 rather than at step 1. For an AI pipeline where every step is a paid model call, that difference is the entire cost argument.

Local development that mirrors production. The dev UI shows the same run-by-run, step-by-step observability as production. Debugging a distributed job is normally the worst part of owning one, and this is the part of the product that most reduces that.

Concurrency control. Per-function and per-event limits, which is how you avoid slamming a downstream API or blowing a rate limit.

TypeScript as a first-class citizen. The SDK is TypeScript-native and types flow through, so a refactor breaks loudly at compile time rather than quietly at 3am.

The event model itself. Once everything is an event, sending one from any part of the system invokes whatever should respond, without the sender knowing who that is. That is genuine decoupling and it is the reason to adopt the tool at all.

What it costs

Pricing is hard to predict before you ship. It scales gently, but the bill is a function of step structure, and step structure is something you get right by building rather than by reading. Expect to overpay while you learn.

Step granularity is a real design decision. A function with twelve fine-grained steps is more recoverable and more expensive. One with three coarse steps is cheaper and loses more on a retry. Choose deliberately, before writing the function rather than after the first invoice.

Retry configuration is available but not discoverable. The defaults are sensible. Finer control exists. Finding it takes longer than it should.

Documentation thins out past the common path. Custom retry policies, complex fan-in and dead-letter handling are the cases where the docs run out and their Discord becomes the real reference.

The failure mode to configure for

The one that bites people: a step calls an external API, that API starts returning 500s, and Inngest does exactly what it promises by retrying with exponential backoff. An hour later the API recovers and thousands of queued retries arrive at once.

Nothing there is a defect. Durable retry is the product working. But max retries per function is configurable and is not on by default in a way that saves you, so set it before you need it rather than after.

Where something else fits better

Trigger.dev, for work that needs a real machine. ffmpeg, large file I/O, or extended runtime on a container. Inngest's serverless execution model is the wrong shape for those.

Plain Vercel cron, for trivial scheduled work. A daily report or an hourly health check does not justify the dependency.

Postgres LISTEN/NOTIFY, when the events are database changes. If your events are already tightly coupled to row changes, the database's own notification mechanism is simpler than adding a platform.

Cron functions rather than events, for genuinely periodic work. Inside Inngest itself, modelling a schedule as an event is the common early mistake. Cron functions exist for exactly that.

How to decide

Inngest fits when the work is event-driven, the steps are expensive enough that restarting from the failure point matters, and the team writes TypeScript. Those three together are a strong case.

It fits badly when the work is a simple schedule, when steps need a real container, or when the events are really just database triggers. Each of those has a cheaper answer.

The direction of travel is worth noting: the product is moving toward agent-runtime framing, which suits durable multi-step AI work. If that is what you are building, it is aiming at you.