Search nomadLab

Durable Execution Pricing: Three Count Steps, One Counts Seconds

Inngest, Temporal and now Lambda all bill per step, and a five-step run costs six of whatever they count. Trigger.dev bills compute-seconds instead. Same workload, four rate cards, and one of them cannot be filled in from public prices.

Updated

The engines have converged. Trigger.dev, Inngest and Temporal all give you the same thing now: break one logical job into steps, checkpoint each step’s result, retry only what failed, and sleep for days without holding a worker open. AWS shipped the same idea into Lambda itself at re:Invent 2025 as durable functions, which suspend for up to a year and stop charging compute while they wait.

So the interesting question is no longer which one has steps. It is what a step costs, and the four answers are not in the same unit. Rates below came off the vendor pricing pages and the AWS price list on 23 August 2026.

What one run of a five-step workflow costs on each platform's meter. Inngest counts six executions, the run itself plus each of the five steps. Temporal counts six Actions, the workflow start plus five activity executions, with each timer counted separately. AWS Lambda durable functions count six durable operations, the start plus five steps, on top of normal Lambda compute. Trigger.dev counts no steps at all: it bills ten seconds of machine time plus one run invocation. One run, five steps, four meters Three of them charge you six times for one logical job. The fourth never counts steps. Inngest6 executions (the run, plus each step) Temporal6 Actions (start, plus each activity); timers count too Lambda durable6 operations at $8 per million, plus normal GB-seconds Trigger.dev0 step charges: 10 machine-seconds, plus 1 invocation Adding a step changes three of these bills. On the fourth it changes nothing unless it takes time. Two of the four also run your code. The other two send it to compute you are paying for elsewhere.
Inngest's own FAQ is explicit: a function with five step.run() calls uses six executions per run. Temporal and Lambda count the same shape under different names.

What each one counts

Billable unitRuns your code?Free entry
Trigger.devMachine-seconds by preset, plus $0.000025 per runYes, on their workers$0 plan with $5 of credits
InngestExecutions: the run plus every stepNo, it calls your endpoints50,000 executions a month
TemporalActions: starts, activities, signals, timers, queriesNo, you run Workers$1,000 of credits, 90 days
Lambda durable functionsDurable operations, plus the usual Lambda metersYes1M requests, 400,000 GB-seconds

The “runs your code” column decides whether the number you are comparing is the whole bill. Temporal and Inngest orchestrate; the compute happens on Workers or serverless endpoints you pay for separately. Trigger.dev and Lambda include it. Any comparison table that lines up all four base prices without saying this is comparing two different things.

The same workload, priced four ways

Take a plain agent shape: one million runs a month, five steps each, ten seconds of compute per run, small machine.

Monthly, us-east-1 rates
Trigger.dev, small-1x$338 compute + $25 invocations = $363
Temporal Cloud, Essentials5M overage Actions × $50/M = $250, plus $100 plan fee = $350, plus your Workers
Lambda durable functions, Arm$133 compute + $48 operations + $0.20 requests = $181, plus payload storage
Inngest, Pro$99 base, then 5M overage executions at rates the page does not publish

That last row is not laziness. Inngest publishes per-unit prices for events, span data and evaluation scores but describes execution overage only as “tiered rates,” so the largest line on a workflow-heavy bill is the one you cannot model before signing up. Everything else in the table came from a published number.

Two things jump out of the rest. Temporal, the one with the enterprise reputation, is within 4% of Trigger.dev at this shape, because the $100 floor stops mattering once real usage arrives. And Lambda undercuts both, which it should: you are getting the primitive without the dashboard, the replay debugger or the timeline UI that the other three spend their engineering on.

Where the step count comes from, precisely

Inngest’s FAQ leaves no room: “An execution is a single durable function run plus each step inside it. If your function has 5 step.run() calls, one run uses 6 executions.” Their own calculator does the same arithmetic, adding runs to steps rather than treating a run as free.

Temporal’s Actions list is longer than most people expect. Workflow starts, resets and continue-as-new; every Activity start and every retry; every timer, including implicit timeouts from AwaitWithTimeout or a condition; every signal, update and query. A retry-heavy workflow bills more than a clean one, which is the correct incentive and a surprising line item the first time a flaky API doubles your Action count. One genuinely nice exception: Actions generated during replay do not count, because replay happens on the Worker and produces no server-side operations.

Lambda counts the same shape and names it differently. From AWS’s own worked example, one execution with two steps and one wait is four operations: the start, the two steps, the wait. At $8 per million, steps are the cheapest of the three step-counters by a wide margin, which makes sense given that AWS is also charging you for the compute.

Trigger.dev is the outlier. It bills $0.0000338 per second on the default small-1x machine plus $0.000025 per run invocation, and never asks how many steps you used. A wait longer than five seconds gets checkpointed and stops the compute meter, and a parent waiting on subtasks is checkpointed too. Adding a sixth step to a Trigger.dev task costs exactly as much as the time it takes.

The meters nobody budgets for

Inngest’s Pro plan has seven meters, not one. Beyond executions: concurrent steps at $25 per 25 above 100, users at $10 each above 15, connected workers at $10 per 10 above 20, events at $0.50 per million above 5M, trace span data at $3 per GB above 5 GB, and evaluation scores at $1.50 per 1,000 above 50K. Observability is metered as a product here rather than bundled, so an agent workload that emits heavy traces gets billed for the traces.

Temporal’s storage split is worth reading twice: Active Storage, used by open workflows, is $0.042 per GB-hour, while Retained Storage, used by closed histories, is $0.00105. That is a 40× difference, and it means long-lived open workflows carrying big payloads cost far more to hold than finished ones cost to keep. The plan fee compounds it: Essentials charges the greater of $100 or 5% of usage, Business the greater of $500 or 10%. The percentage goes up with the tier, so scaling into Business doubles the tax on the same consumption.

And if you enable Fairness on a namespace, Temporal adds 0.1 Actions per Action for every hour the feature is on, whether or not any workflow uses a fairness key. A namespace doing 10,000 Actions an hour bills 11,000.

The licenses are three different answers

This is the part that outlasts every price in this post.

Trigger.dev is Apache 2.0, and the self-hosting story is real: multiple containers plus Postgres and Redis, so budget a sprint rather than an afternoon, but nothing is held back from you.

Temporal’s server is MIT. Self-hosting a cluster expects you to understand persistence tuning and matching service shards, which is why most small teams should not, but the license is not what stops them.

Inngest is SSPL 1.0 with an Apache 2.0 future license: each release becomes Apache 2.0 on its third anniversary. So the code you can run today under a permissive license is the code from 2023. That is a materially different offer from the other two, and it almost never shows up in comparisons that call all three open source.

Picking without a benchmark

If your workflows are short and numerous, the step-counters get expensive in a way that is easy to model and hard to notice: every refactor that splits a step in two raises the bill. If your workflows are long and few, the second-counters get expensive instead, and Trigger.dev’s checkpointing on waits is what keeps that from being brutal.

If auditability is a stated requirement rather than a nice-to-have, Temporal is the one with deterministic replay, signals, versioning of running workflows, and a history you can reconstruct months later. Its programming model asks for that in return: no Date.now(), no random values, no I/O in workflow code, all of it pushed through activities. That constraint is the feature, and it is also the week your team spends before anything ships.

If you are already deep in AWS, durable functions deserve a look before any of the three, and they did not exist when most of the comparisons on this topic were written. You give up the timeline UI and get the primitive at $8 per million operations, inside the function you were already deploying.

The cheapest evaluation is not a benchmark. Take one workflow you already run, count its steps, multiply by a million, and put that number next to the four meters above. The answer usually stops being contested at that point.

Keep reading