Durable execution is one of those ideas that sounds like infrastructure trivia and turns out to be the answer to a class of bugs that engineers have been writing around for decades. The problem is this. You have a business process with several steps: charge the card, provision the account, send the welcome email, notify the sales system. Each step calls something that can fail.
The naive implementation is a function that does all four in sequence, and the naive failure handling is to retry the function. Which charges the card again. So you add idempotency keys, and a status table to record which steps completed, and logic to skip the completed ones on retry, and now you have written a small, buggy, bespoke workflow engine inside your application, and every engineer who has done this recognises the description immediately. Durable execution generalises the fix.
The engine records the outcome of each step as it completes, and if the process dies at step three, it resumes at step three with the results of steps one and two intact. You write what looks like ordinary sequential code and get crash-resilience for free. Inngest's documentation explains this well, and the explanation is the most valuable thing in it because the concept transfers to Temporal, to Restate, to Trigger.dev and to anything else in the category. The primitive set is genuinely rich and the docs cover it properly.
Sleep, which lets a workflow wait days or weeks without holding a process open, is the one that most changes what you can build: a trial expiry flow, a dunning sequence, a multi-day onboarding campaign all become straightforward sequential code rather than a cron job reading a state table. Fan-out for parallel work, debounce for collapsing bursts of events, priority queues for making sure the important work is not stuck behind a backlog of the unimportant. These are the things you end up needing, and having them in the engine rather than assembled from Redis and hope is the point. The event-driven model is the architectural choice that distinguishes Inngest from its neighbours, and it is well matched to a particular situation.
Functions are triggered by events, crons or webhooks, and they live close to your existing application rather than in a separately deployed worker fleet. For a team with an existing service that wants durable background work without standing up and operating a new deployment target, that is a lower-friction path than the alternatives. The local development story is also better than this category usually manages, which sounds like a minor point and is not: a distributed execution engine you cannot run and debug on your laptop is a distributed execution engine your team will be slow with for months. The licence is the thing to resolve before anything else, and it is where I would push back on how prominently it is presented.
Inngest is licensed under SSPL. SSPL is not an OSI-approved open source licence, and its terms around offering the software as a service are aggressive enough that many organisations have blanket policies against it. Contrast this directly with Trigger.dev, the closest comparable product, which is Apache 2.0 and genuinely permissive, with self-hosting and unlimited runs available without a licensing conversation. That is not a small difference between two otherwise similar products, and a team evaluating on features alone will miss it entirely.
If self-hosting or licence permissiveness matters to you at all, this consideration should probably lead your evaluation rather than follow it. I want to be fair about the commercial logic, which is the same logic that drove Snowplow and MongoDB to similar decisions and is a rational response to cloud providers monetising other people's engineering. But the practical consequence for a buyer is what it is. The gap I would most want filled is the honest negative guidance.
Durable execution is a genuinely good idea and it is also more machinery than a great many problems require. A large share of background work is a job that needs to run once, might fail, and can simply be retried from the start with no harm done, and for that a queue and a worker is a smaller, more debuggable, cheaper answer with no new vendor attached. The docs never suggest this, because no vendor writes a page explaining that you might not need them. The rough heuristic worth holding is that durable execution earns its complexity when your process has multiple steps with side effects that must not repeat, when it spans a long enough period that holding a process open is impractical, or when partial completion leaves you in a state that is expensive to reason about.
If none of those apply, use a queue. Debugging deserves a warning too. When a durable workflow with fifteen steps behaves incorrectly on day four of a sleep, you are reasoning about a distributed system with persisted state across time, and the tooling for that is better than nothing but not as good as a stack trace. The documentation is more enthusiastic about how easy it is to write these workflows than about what it takes to diagnose one, which is the usual asymmetry.
Three point eight. A clear explanation of a genuinely valuable idea with a rich and well-documented primitive set, marked down for SSPL licensing that a comparable competitor avoids, no teaching layer, and no honesty about when the simpler tool is the right one.