Durable Execution Pricing in 2026: How Temporal, Step Functions and Others Bill You

Durable execution pricing comes in two forms. Metered platforms (Temporal Cloud, AWS Step Functions, Cloudflare Workflows, DBOS) bill per unit of work, and each defines the unit differently. Capacity platforms (Azure Durable Task Scheduler Dedicated, Diagrid) bill for reserved size. For AI agents, retries, fan-out and waiting move the bill differently on each.

Prices checked 29 Sep 2026 against each vendor's pricing page. Rates are list prices in US dollars, for US regions where the vendor prices by region.

Durable execution pricing at a glance

Your agent calls a tool. The call fails, the runtime retries, and the fourth attempt goes through. One piece of useful work, four attempts, three of them wasted.

What those three wasted attempts add to your durable execution cost depends entirely on which platform sits underneath them. Temporal's cost guidance is explicit that every Activity retry counts as one Action, so you're paying for all four. Cloudflare draws the opposite line. Its pricing reference says step count leaves out rollback handlers and retries, so those three failures never reach that meter at all.

Same failure, same agent, two different answers about who pays for it.

Both are orchestration bills, the platform's charge for running your workflow, and one of the cost lines in our guide to running AI agents in production. The tokens that tool call burned are a separate line, covered in what a failed run costs in tokens. The orchestration bill moves on how your agent behaves, and your model vendor's price list has nothing to do with it.

Neither "usage-based" nor "capacity" tells you what you'll be charged for. The counting rules do, so that's what the rest of this covers.

How metered durable execution pricing works

Metered pricing, often sold as per-action pricing, charges you for units of work the runtime performs. The difference between platforms is what each one treats as a unit, and every vendor decides that for itself. That decision shapes your bill more than the headline rate does.

Temporal Cloud pricing

Temporal Cloud calls its unit an Action, and it covers more than it sounds like. The full list of billable Actions runs to more than twenty operations. These are the ones an agent workflow hits:

Every line is something an ordinary workflow does on an ordinary day, which is why the count climbs faster than teams expect.

Temporal Cloud pricing starts at $50 per million Actions. On the Developer plan that rate holds at every volume. On Business and above it slides, from $50 per million for the first five million down to $25 per million between one hundred and two hundred million. Active storage adds $0.042 per gigabyte-hour and retained storage $0.00105.

The plan fee sits on top. Developer has no base fee and adds 10% of your usage spend, with nothing included. Business costs the greater of $500 a month or 10% of usage, and includes 2.5 million Actions, 2.5 GB of active storage and 100 GB of retained storage.

AWS Step Functions pricing

AWS Step Functions sells two workflow types priced on different meters. Standard workflows, the durable, long-running kind, bill per state transition: $0.000025 each in US East (N. Virginia), after a free tier of 4,000 transitions a month. AWS states that when a step has retry error handling, "each retry will be charged as an additional state transition."

Express workflows cost $1.00 per million requests plus $0.00001667 per GB-second of duration instead. An agent that waits hours for an approval belongs on Standard, so the transition count is the number to model.

Cloudflare Workflows pricing

Cloudflare Workflows pricing runs on four meters at once. On the Workers Paid plan:

• Steps: 500,000 included per month, then $0.80 per additional 100,000
• Requests: 10 million included, then $0.30 per million
• CPU time: 30 million CPU milliseconds included, then $0.02 per million
• Storage: 1 GB-month included, then $0.20 per GB-month

The free plan gives 3,000 steps a day. A workload that costs one Action on Temporal doesn't cost one step on Cloudflare, and no conversion exists between them.

DBOS pricing

DBOS sells subscriptions with a checkpoint allowance. Pro costs $99 a month and includes a million checkpoints, defined as workflows, steps, and transactions, with more at $50 per million. Teams costs $499 a month with 10 million checkpoints and $40 per million after that. Enterprise is custom. The pricing page doesn't say whether a retried step writes a new checkpoint, so ask before you model a retry-heavy workload.

What the meters exclude

The bigger differences are in what each meter leaves out, and retries are the clearest case. Temporal and AWS bill every retry; Cloudflare bills none. Take one million agent runs a month, each making 10 tool calls, where 30% of calls fail and succeed on the fourth attempt. That's 10 million calls and 9 million retries. Priced at each vendor's published per-unit rate, the retries alone cost:

This is the retry line only, and Temporal's Business tiers would lower the per-Action rate at this volume. On two platforms your failure rate is a line on the invoice, and on the third it isn't.

Idle time is treated differently again. A sleeping workflow still costs a step on Cloudflare, since the changelog that introduced step billing defines a step as including "sleeping or waiting for events," yet that same workflow incurs no CPU time. One pause, charged on one meter and not the other.

How capacity pricing works

Flat pricing charges you for capacity you reserve, not for work the runtime performs. Execution volume stops moving the bill. What you buy instead is a size, and you have to pick it before the month starts.

Azure Durable Task Scheduler pricing

Microsoft's Durable Task Scheduler sells one product in two versions, or SKUs, and publishes a spend formula for each in its billing documentation.

Microsoft defines an action as a message the scheduler sends to your application to trigger an orchestrator, activity, or entity function. Its example counts two per activity: one to schedule it and one to process the result. On the Dedicated side you buy Capacity Units (CUs) up front at a fixed monthly cost per CU set regionally, and the documentation is blunt that this is "Not 'per action' billing." Azure's price list puts a Dedicated CU at $0.684932 an hour in East US, about $500 a month. Rates for both SKUs are on the Azure Functions pricing page. Compute for your workers is billed separately.

One caution on vocabulary. Microsoft's action and Temporal's Action share a name and not much else. Temporal counts retries, timers, and heartbeats, while Microsoft counts messages dispatched to your application.

What each model asks you to forecast

Flat pricing doesn't remove the forecast. It changes which number you have to get right.

Consumption asks for a number your workload produces: how many messages your orchestrations will dispatch. Dedicated looks like the way out, because you pick the CU count yourself, until you read Microsoft's sizing method and find the same forecast underneath.

The documentation works CUs out from projected volume. Take your monthly actions, divide by 2,628,000 for actions per second, then divide again by the 2,000 actions per second each CU supports. One worked example runs 20 million orchestrations at 12 actions each, arrives at roughly 91 actions per second, and fits comfortably inside a single CU.

So the CU count is a volume forecast with an extra division step, estimating the quantity Consumption would have billed you for directly. What changes is the penalty for getting it wrong. Underestimate on Consumption and the meter charges you more. On Dedicated you meet a ceiling instead, since a deployment supports at most three CUs and Microsoft doesn't say what happens when you reach them.

Diagrid pricing

Diagrid runs concurrency-based pricing, the same model with a different unit. The two paid tiers in its pricing calculator, Dedicated Cloud and BYOC (Bring Your Own Cloud), are both sized on concurrent workflows. Diagrid counts that as the number of workflow instances running at a given time, with child workflows counted separately from their parents and repeat instances of the same workflow counted separately as well.

The bands run 0 to 200, 201 to 500, 501 to 1,000, and 1,001 to 2,000 concurrent workflows. Dedicated Cloud starts at $1,499 a month, or $1,199 billed annually, and BYOC starts at $1,999 a month, or $1,599 billed annually. A free Cloud tier covers development work. Workflows and activities aren't metered at all, so the pricing page tells you to "size for concurrency only," never for execution volume. Retries, timers and heartbeats don't change the bill. For a side-by-side on features as well as price, see Diagrid vs Temporal.

What agentic workloads do to metered pricing

Temporal publishes its own list of what runs up large Action counts, in guidance written to help customers spend less. The platform wrote it, so it has no reason to overstate the problem. It names five patterns. Many activities per workflow. Frequent signals, queries, or updates. Long-running activities with heartbeats. High retry rates on activities. And extensive query usage. Each retry and each heartbeat counts as one Action.

Why agent workloads hit those patterns

Four of those five describe an ordinary agent run. Nothing misconfigured, nothing abused.

One user request turns into a run of reasoning steps, tool calls, and handoffs to sub-agents. That's pattern one, and your team hasn't done anything wrong yet. Those calls then fail in production, where failure is "a given rather than an exception", and each retry adds another Action. They run long enough to need heartbeats. Agents that pause for a human approval take signals and updates to come back.

The fifth, extensive query usage, is an observability habit your team chose, not something the agent does on its own.

The number nobody can forecast

Underneath sits a harder problem. An agent decides its own step count. The same request might take four tool calls or fourteen, depending on what the model concludes along the way. You can't know the unit count before the run, which means you can't know the bill. Diagrid describes it as cost that "swings with every loop you can't predict".

None of this makes metered pricing wrong. It ties your bill to how much the agent reasons, and that's the variable your team has least control over.

What agentic workloads do to flat pricing

Flat pricing takes that variance out of the bill. An agent that takes fourteen tool calls where you expected four costs exactly what one that takes four costs.

What it asks in return is a single number, decided before the month starts.

Fan-out sets that number, not you

Diagrid's documentation lists fanning work out across application instances as one of the reasons to reach for child workflows, alongside composing larger orchestrations and isolating retry boundaries.

Diagrid counts workflow instances, so when an agent fans out through child workflows, five sub-agents running in parallel occupy six slots instead of one. Nothing in your tier selection decided that. The model did, mid-run.

The same behavior costs you on the other model too. Temporal prices a child workflow start at two Actions against an activity's one, so fanning out runs up a higher unit count there for the same reason it fills more slots here. Two different currencies, one behavior driving both, and it isn't a behavior you scheduled.

You buy for the peak and pay through the quiet hours

Bands are bought in advance, so your busiest moment sets the size. A workload that hits four hundred concurrent workflows during a nightly batch and sits at sixty the rest of the day still pays for the band covering four hundred, every day of the month.

This is where metered pricing wins outright. Temporal's Developer plan has no base fee, and a test workflow of 10,000 Actions costs 55 cents by Temporal's own example. A capacity band gets paid for whether you fill it or not.

The question no pricing page answers

Diagrid's documentation says most long-running workflows spend nearly all their wall-clock time durably suspended on a timer or an event, and it classifies an instance in that condition as running.

That describes runtime state, not billing. If approval-heavy agents spend most of their hours suspended, then whether a parked instance holds a slot is the difference between sizing for the work in flight and sizing for every workflow you've opened and not yet closed. For a human-in-the-loop process those two numbers may be nowhere near each other.

Before you sign: three checks

The rate is the easiest number to find and the least useful. Cloudflare's pricing reference defines a step, circularly, as the number of steps your workflows execute; the working definition sits in the July 2026 changelog. Microsoft names a three-CU ceiling and stays quiet about what happens at it. So, three things before you sign:

1. Read the counting rules for the platform you're considering, and expect them to live somewhere other than the pricing page. The summary table links to each vendor's source.
2. Model your own retry rate against those rules. Take last month's tool-call failure rate, multiply it through as in the retry table above, and you'll know whether your failures are free or billable.
3. Ask any capacity-priced vendor how a workflow waiting on a timer or an approval gets counted, and get the answer in writing.

If you're still building the shortlist, our roundup of Temporal alternatives compares the platforms on more than price. For cost drivers outside the orchestration meter entirely, see the economics of running agents at scale.

Frequently asked questions