Open-source durable workflows keep their resume point where you can read it

A durable workflow is one that can name its resume point

Every definition of durable execution describes the same symptom going away: work that dies with its process. Temporal puts it in three words, "Durable Execution is crash-proof execution." Restate describes an engine that "records each step of a function as it runs" so ordinary code survives "crashes, restarts, and infrastructure failures."

Both are accurate, and neither settles the choice. Before comparing tools, ask where the workflow keeps its place. Call that the resume point: the record a restarted system reads to decide what happens next. Two questions decide most of the argument. What is in the record, and who can read it?

A resume point built from completed steps answers the first: an event history, a checkpoint row, a committed file. The second question is the one teams skip, and it decides whether the record is an asset or a liability. A history you can open in your own database is a different object from one a vendor holds for you.

Four designs that keep a resume point

An orchestrator keeps an event history outside your code. Temporal's model is Workflows and Activities dispatched to polling workers, with Activities, Timers, Signals, Queries, Updates and Schedules as the durable steps. Replay rebuilds state from that history, which is why the code has to be deterministic.

A queue with steps re-delivers what failed. Inngest combines triggers (events, cron, webhooks) with steps and flow control, and its functions sync with the Inngest Platform or a self-hosted Inngest server. Trigger.dev covers similar ground for TypeScript: long tasks, retries, queues and a pause until a person approves.

A library checkpoints into the database you already run. DBOS builds durable workflows on Postgres, and says the mechanism is "entirely contained in this open-source library, there's no additional infrastructure for you to configure or manage."

A runtime keeps a log beside the code. Restate runs as a self-contained single binary, started with docker run, Homebrew or npx @restatedev/restate-server, and records each step of a function as it runs.

All four answer "where did we stop" with a record the tool owns. None has an opinion about who accepts the result, because that is not a runtime concern. That gap grows with the work.

The four shapes of workflow, and how much durability each needs

Durability is a requirement per shape, and the shapes ask very different things of the record.

Short request and response. A click, a query, an answer in a second. If the call fails the caller retries, so the durability you need is an idempotency key that stops the retry from charging the card twice. An orchestrator here is a second system for a guarantee the handler already gives you.

Long-running with an approval in the middle. A request goes out and a person answers tomorrow. The wait is state, and held in a sleeping thread it dies with the next deploy. This is the shape where a durable engine earns its cost.

Scheduled batch. A report at 09:00 on weekdays. The clock lives outside the process you redeploy, and each fire is keyed on its schedule slot so a retry does not produce two reports.

Event-driven chains. One event fans out across several services. Losing nothing and running nothing twice is a dedupe problem before a durability problem.

What an agent's workflow resumes from

Agent work is the long-running shape with one difference: the steps are edits to files, and the output is a diff somebody has to read before it counts.

Kortix runs each session in its own sandbox, cloned from the project repo, on a new branch named after the session id. The agent prompt states the consequence plainly:

The session you're in is an isolated sandbox — an ephemeral branch of this repo … Only what you commit + push survives.

Read that as a durability model: a restart uses the branch and the commits on it. A session that dies mid-edit leaves whatever it pushed, and it does not resume where it stopped.

Work then lands the way code lands. The agent commits, pushes its session branch and opens a change request against the project's default branch, and a person with the merge permission merges it. Merge is default-deny for agents.

Two things follow. The record of what happened is a git history you can read, diff and grep on your own remote, so an audit is a checkout rather than a support ticket. And the approval sits in that same record, so the workflow cannot be called finished while nobody has looked at it.

The claim is narrow. For step-level replay of a function across a crash, an engine is the right tool, and that is what Temporal, Restate, Inngest and DBOS are built for. For an agent editing twelve files over two days, the branch is the resume point that survives, and the change request is what a person acts on. Two other questions decide that split: what durable execution means and which durable execution engine to choose.

Starting a run when nobody is there

A durable workflow that only starts when a person clicks does not carry much weight. Kortix triggers start a session with nobody present, in four types. cron fires on a schedule slot or a single run_at. webhook fires on a signed POST. event fires when something happens in a connected app. monitor fires when a command in your repository prints a line on stdout. The docs page carries the CLI and the signing rules: read the docs.

A reminder is a narrower object: it re-prompts one existing session later, once or on repeat, which is how a wait on a person comes back to life without a second run.

What to look at when a run stops moving

Silent failure is the expensive kind, and three places show where a workflow is without a debugger. The trigger's run list comes first: each fire has a run id, status, duration, cost and session, and a failed run carries its failure text. The branch comes second, because a session whose change request is still open is work waiting on a person, not work in progress. The audit log comes third. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan, so check before you need the trail.

Which one to reach for

If the failure you fear is a lost function call inside one service, use an engine. Temporal or Restate gives you an orchestrator and its history, DBOS puts the checkpoint in the Postgres you already run, and Inngest keeps steps and flow control together for event-driven code.

If the failure you fear is an agent's work vanishing before anyone read it, keep the resume point in git. A branch, a commit and a change request give you a record you own and an approval step that cannot be skipped.

If the workflow is mostly a wait on a person, ask what the wait is stored in. An engine holds it as state, and a session holds it as an open change request plus a reminder.