// vendor truthby JoshApril 24, 20265 min read

Honest Review: Inngest After 6 Months in Production

Six months ago I bet on Inngest for all my background work. Here's what's worked, the rough edges, and whether I'd make the same bet today.

Honest Review: Inngest After 6 Months in Production

Six months ago I made Inngest my default for any background work — async jobs, event-driven workflows, scheduled tasks. Across multiple client projects. Here's whether the bet paid off.

What worked

Step durability. This is the killer feature. Each step in a function is durably checkpointed. If a function fails at step 5 of 12, it restarts at step 5. For AI pipelines with expensive intermediate steps, this saves real money on retries.

Local dev mirroring production. The dev UI shows the same observability as production. You see your function runs, step by step, with the same fidelity. Debugging is meaningfully faster.

Concurrency control. Per-function and per-event concurrency limits. Useful for not slamming an external API or stay within rate limits.

TypeScript first-class. Inngest's SDK is TypeScript-native. Types flow through. Refactors don't break invisibly.

Event-driven model. Once I internalized that everything is events, building things became easier. Sending an event from one part of the system invokes the right functions automatically.

What was rough

Pricing predictability. The pricing scales gently but it's hard to predict before you've shipped real workloads. I overpaid for a couple months because I had inefficient step structures.

Step structure learning curve. Knowing when to make something a step (durable, checkpointed) versus inline (faster, not checkpointed) takes a few weeks of building to internalize.

Some edge cases on retries. The default retry behavior is good but I had a few cases where I wanted finer control. Configurable but not always discoverable.

Documentation depth. The docs cover the common cases well. The more advanced patterns (custom retry policies, complex fan-in, dead-letter handling) required asking in their Discord or reading the codebase.

What I'd do differently

Plan step structure before coding. A function with 12 fine-grained steps is more durable but more expensive. A function with 3 coarse steps is cheaper but less recoverable. Pick the right granularity for the function's cost-of-replay.

Use cron functions for true periodic work. I tried to use events for some scheduled tasks. Cron functions are cleaner for purely time-driven work.

Set concurrency limits early. I didn't think about concurrency until I had an incident. Set sensible limits from day one.

What broke

One production incident in 6 months. A function had a step that called an external API. The external API started returning 500s for an hour. Inngest dutifully retried with exponential backoff. By the time the API recovered, I had thousands of retries queued.

Resolution: add max retries per function. Inngest supports this. I hadn't configured it. My mistake, not Inngest's.

Otherwise, durability has been solid. No silent failures. No lost runs.

What I'd reach for instead

Trigger.dev for tasks needing real machines. If a task needs ffmpeg, large file I/O, or extended runtime on a real container, Trigger.dev's model fits better. Inngest's serverless model has limits.

Raw Vercel cron for trivial scheduled work. Daily 4-AM report. Hourly health check. Don't pull in Inngest if cron is enough.

Postgres LISTEN/NOTIFY for in-DB event work. If your events are tightly coupled to database changes, Postgres notification mechanisms can be simpler than Inngest.

The bottom line

Inngest has earned the default slot for background work in my stack. Six months in I have confidence in its durability, observability, and dev velocity.

The pricing is competitive at the volumes I run. The team responds in Discord. The product is improving.

If you're picking a background job platform today, Inngest is my recommendation. Trigger.dev is the strong alternative if your workloads need real machines.

What changes in 12 months

Inngest will continue to add AI-specific primitives. The "agent runtime" framing is where they're heading. If you're building AI agents that need durability across long-running multi-step work, Inngest is positioning itself as the platform.

I expect to be using Inngest more, not less, over the next year. The bet paid off.

inngestbackground jobsreviewai engineering
// go deeper

Want the full guide? Check out our deep-dive page for more context, FAQs, and resources.

read the full guide
// keep reading

Related posts

// ready to ship?

Let's build yours.

Reading is the easy part. We do the work. Tell us what's broken and we'll tell you straight up whether we can help.