Durable execution
What is durable execution?
Durable execution is a way of running a long process so it survives the machine it started on. The engine records every step and its result. When the worker crashes, redeploys or loses the network, the process is rebuilt by replaying that history and carries on from where it stopped.
The reason it matters is narrower than the marketing suggests. It is not that failure stops happening. It is that you stop writing the code that deals with failure, and that code is where most of the bugs in a long-running system actually live.
The problem it removes
Take an order that charges a card, reserves stock, books a carrier and emails a confirmation. Four steps, three of which can fail, one of which can take three days. Written normally, that becomes four handlers, a status column, a retry table, a nightly job that finds stuck rows, and a runbook for the operations team. Most of that code exists to describe what should happen when something goes wrong halfway.
Under durable execution it is one function that reads top to bottom, with the waits written as waits. The engine holds the position. A crash three days in resumes at the carrier step with the card still charged exactly once.
| What fails | Written by hand | Durable execution |
|---|---|---|
| Worker crashes mid-order | Status column says in-progress forever; a human repairs it | Replays to the last completed step and continues |
| Payment API times out | Retry loop, and a risk of charging twice | Step retried under a policy; the charge stays exactly once |
| Deploy lands mid-flight | In-flight work is lost or half-applied | Runs continue; versioning decides which code they use |
| Waiting three days on a carrier | Cron job scans for stuck rows | The workflow simply waits, holding its place |
| Someone asks what happened on order 4471 | Grep the logs, if they are still retained | Query the run history: every step, input and retry |
The part the tutorials skip
Replay puts real rules on your code
Because recovery works by replaying history, workflow code has to produce the same result every time it runs. That rules out reading the clock, generating a random number or a UUID, and calling out to a network directly from workflow code. Each of those has to move into a recorded step, or the replay diverges from the history and the run fails in a way that reads as a mystery the first time you see it.
This is the single most common way a first durable workflow goes wrong, and it is a design constraint rather than a bug. It is worth knowing before you choose the approach, because it shapes how the code is written from the first line.
Where we use it
APIs and durable systems
The service line, and how an engagement usually starts
AI workflow automation
Long-running processes with model calls inside them
Agentic AI development
Agents that park for approval and survive a restart
Durable execution with Temporal
Our Temporal capability in full
Auto Approve
Twice the loans, no new agents
Durable RAG with Temporal
Working code, not an illustration
FAQ
Durable execution: common questions
What is durable execution?
A way of running a long process so that it survives the machine it started on. The engine records every step and its result, and if the worker crashes, redeploys or loses the network, the process is rebuilt by replaying that history and continues from where it stopped. The practical effect is that a workflow can run for days across restarts without anybody writing state-machine and retry code by hand.
How is durable execution different from a queue or a cron job?
A queue moves messages and leaves the sequencing to you. Durable execution holds the sequence itself, including the waits, so "charge the card, then wait up to three days for the carrier, then either confirm or refund" is one readable function rather than four handlers and a state column. If a step fails, the engine retries that step rather than replaying the side effects around it.
What are the main durable execution frameworks?
Temporal is the most widely deployed, and it is the one we build on and partner with. Others in the category include Restate, Inngest, DBOS, Azure Durable Functions and AWS Step Functions. They differ mainly in whether you write ordinary code or a state definition, whether they are hosted or self-run, and how they handle versioning a workflow that is already in flight.
When is durable execution not worth it?
For anything short and idempotent, it is overhead you will feel. A request that finishes in a second and can simply be retried does not need replay, a worker fleet, or the discipline that comes with them. The line is roughly: does a partial failure here leave the business in a state somebody has to repair by hand? If not, use a queue.
What is the hardest part in practice?
Versioning. A workflow that runs for three days will have code deployed underneath it mid-flight, and changing the order of steps changes the history that replay depends on. Every framework has a mechanism for this, and every team learns it the second time rather than the first. Budget for it before the first long-running workflow ships, not after.
Does durable execution help with AI agents?
It is close to a requirement once an agent does more than one thing. Model calls fail far more often than database calls, agent runs are long, and a half-completed sequence of tool calls is exactly the state nobody wants to unpick. Approvals become natural too: the run parks waiting for a person and survives a restart while it waits.