TL;DR
- Buy durable execution when a workflow must retain progress across crashes, waits and approvals. A scheduled function that starts again tomorrow does not necessarily know which side effects already happened.
- Temporal fits complex engineering-owned orchestration. Inngest fits event-driven application workflows with explicit steps. Trigger.dev fits code tasks where compute and waits need different treatment. Restate is relevant for durable service interactions and state.
- Durable orchestration does not automatically make an external CRM write or email exactly once. Use stable operation identifiers and reconcile ambiguous outcomes before retrying.
- Price actions/steps, active compute, history storage and workers separately. Seven days elapsed is different from seven days of running compute.
The failure is between steps
A revenue workflow might enrich an account, wait for a manager, create a CRM task and then notify a seller. If the process crashes after creating the task but before recording success, restarting the whole function can create a duplicate. If it waits in memory for a week, a deployment can lose the approval state.
Durable execution retains enough history and state to resume the work after failure. The purchase concerns those semantics, rather than where a short function is hosted. Our cloud agent platform guide covers the surrounding deployment decision, while the agent framework comparison covers application orchestration choices.
Define which events the workflow owns and which effects an external system owns. The engine can know that an activity should run again; only the external API or your reconciliation logic can establish whether the previous write happened. This distinction is more valuable than an unqualified promise that work “never fails”.
Four execution models
| Engine | Useful fit | Pricing basis to model | Operating consideration |
|---|---|---|---|
| Temporal | Complex long-lived engineering workflows | Cloud actions/storage plus workers | Workflow code and worker lifecycle require discipline |
| Inngest | Application events and resumable steps | Runs/steps and plan limits | Total run length includes waits |
| Trigger.dev | Durable background tasks | Active machine time and platform usage | Size compute for actual execution, not elapsed waits |
| Restate | Durable service calls and state | Durable actions plus deployment costs | Model service identity and state ownership explicitly |
Temporal
Temporal's documentation describes maintaining workflow state and progress through failures. Its Cloud cost explanation separates actions and storage. That fits a team whose process has many activities, branches and recovery requirements and who can maintain workers and compatible workflow code.
The important trade-off is operational sophistication. The workflow's durable history changes how code upgrades and nondeterministic operations should be handled. Keep external calls in the appropriate activity boundary and make side effects safe to reconcile. A managed service reduces service hosting work but does not write correct application semantics for you.
Choose it when complex, business-critical processes justify the learning and operational ownership. It is overbuilt for a simple nightly read-only report where restarting the whole job is inexpensive. Obtain the current action/storage rates, support terms and worker infrastructure budget for your actual workload.
Inngest
Inngest's step primitives describe reusing earlier results when later work retries, with sleep and event-wait primitives. Its usage limits make clear that total run length includes waits. The current Free plan lists a 30-day maximum including sleeps, so a seven-day wait alone does not imply a paid upgrade. Execution allowance, history retention and concurrency can still determine the plan.
This is useful for an application team that wants explicit resumable units around event-driven work. Design steps so a saved result remains valid when reused. For example, an account's enrichment from a week ago may be acceptable, while a permission check should be repeated immediately before a write.
The pricing page advises comparing actual steps and execution patterns. Choose it for a maintainable event/step model; avoid assuming a headline monthly plan prices every long-lived approval or high-fanout run. Include retention and concurrency requirements in the commercial check.
Trigger.dev
Trigger.dev's pricing separates machine execution from checkpointed waits and describes how waits longer than five seconds are treated. This is relevant to a task that spends seconds researching, days waiting for approval and seconds writing to a CRM.
Its attraction is a code-task model with durable execution and an explicit compute basis. Price the machine size and active duration for extraction, file processing or other heavy work. Sleeping efficiently does not make an inefficient active task cheap.
Choose it where the team's task code and deployment model fit naturally. Check the current task/runtime, retention and concurrency requirements. It is a weaker choice if the team needs a different service/state abstraction and would recreate that abstraction awkwardly inside a background task.
Restate
Restate's service concepts distinguish durable service calls, keyed state and workflow lifecycle features. The pricing page did not expose a readable current tariff in this check. Obtain the current Cloud action definitions and deployment/support quote; do not assume that one business process equals one billable unit.
This is relevant where several services must coordinate reliably and the team wants explicit durable state ownership. Define the key carefully: an account, tenant and operation may require different identities. Sharing state under an overly broad key can serialize unrelated work or mix client context.
Choose it for a service architecture that benefits from those semantics. Avoid comparing its action count directly with another vendor's steps without modelling the same process. Self-managed and cloud choices also have different infrastructure and support responsibilities.
Design a seven-day approval workflow
Give the process a stable identifier such as tenant, account and campaign version. Retrieve data, save the accepted research result and request approval. The approval event must identify the same operation and the exact proposed action. A vague “approved” event attached to an account should not authorise every later task on that account.
Wait durably with a deadline. If no answer arrives by day seven, expire the action or route it to a named owner. After approval, recheck the account's suppression state, destination permissions and any fact whose age changes the action. The stored research result remains evidence; it should not freeze all future reality.
Before the CRM write, create an operation key. Where the API supports idempotency, pass it consistently. Otherwise retain an external operation marker or query the destination to determine whether the intended record already exists. A timeout after sending the request is an ambiguous outcome, not automatic proof of failure.
Only notify the seller after the write is confirmed. Save the receipt and destination ID. If the notification fails, retry the notification rather than rewriting the CRM task. The ABM Account Scoring Template provides a practical place to define the fit decision that precedes this workflow.
Calculate active work and waiting state
Assume 10,000 workflows monthly, each with eight durable work units and 30 seconds of active processing, plus a seven-day wait. That is 80,000 work units and 300,000 active seconds, or 83.3 compute hours. The vendor's billable actions may exceed eight per workflow because starting, completion, waits, retries and internal events can have their own treatment.
If arrivals are roughly steady and every workflow waits seven days, the average waiting population is about 2,333 workflows: 10,000 divided by a 30-day month, multiplied by seven. This is an illustrative planning estimate. Burst arrivals and variable approval delays change concurrency and storage needs.
Assume platform usage costs $100, workers/compute $80 and maintenance takes six hours at $60 per hour. Total hypothetical operating cost is $540 monthly, before model and enrichment fees. One hundred exceptions taking ten minutes each add $1,000 of operator work. Reliability economics therefore include recoverability and exception effort, not just the cheapest step tariff.
Choose the engine your team can operate
Use a representative fixture: crash after enrichment, lose an approval notification, time out after a successful CRM write and deploy an updated workflow while old runs are waiting. Inspect the resumed state and destination records. Require the process to explain what happened instead of merely eventually returning a green status.
Choose Temporal for complex engineering-owned workflows, Inngest for an event/step application model, Trigger.dev for durable code tasks with active compute, or Restate for durable services and state. A simpler Zapier/n8n workflow can still be appropriate where its documented persistence and recovery behaviour meet the requirement. Buy stronger semantics only where the failure and waiting model demands them.
FAQ
Does durable execution guarantee exactly one CRM write?
It guarantees only the semantics the engine documents for its own execution. External writes still need idempotency or reconciliation. Treat a timeout after sending as ambiguous and inspect the destination before repeating a consequential operation.
Are seven-day waits billed as seven days of compute?
Not necessarily. Many engines persist waiting state instead of holding a worker active. Check the chosen product's wait, storage and run-duration rules, then price active work separately from elapsed time. The products' billing units are not interchangeable.
Can we change code while workflows wait?
Usually there are documented deployment/versioning mechanisms, but compatibility is part of the implementation. Test the upgrade with in-flight runs and retain the version that owns each history. Do not assume a normal stateless deployment procedure safely handles every durable process.
When is an ordinary scheduled job enough?
When the job can restart safely from its inputs, does not hold long-lived approval state and has inexpensive, reconcilable side effects. Durable execution earns its cost when partial progress, long waits or costly duplicate actions make a fresh restart inadequate.
