How durable execution works

A normal function call disappears with its process. Runlane first stores the request to do the work, then lets a worker execute it. If the worker stops, the stored run is still there.

A run is not an attempt

The run is the durable record of the work. It contains the validated payload, current status, timing, output, failure, and event history.

An attempt is one worker trying to execute that run. A retry, release, deploy, or recovered worker can start another attempt. Each new attempt calls the task handler from the beginning.

This separation lets Runlane keep the work even when a process disappears.

What survives a restart

With a durable lane, Runlane stores:

• the run and its event history;
• retry and wait state;
• worker ownership and deadlines;
• completed durable step results;
• schedule occurrences and pending delivery work.

The local lane uses the same model in memory, but its data disappears when the process exits. Production lanes store it in Postgres.

What durability does not guarantee

Durable execution does not make arbitrary code run exactly once. An external API call can succeed just before the worker stops, leaving Runlane without a stored success. Recovery may run that code again.

Make repeated execution safe. Use the external provider's idempotency feature, or wrap the call in a durable step and give the provider a stable idempotency token.

Ordinary local variables do not survive an attempt. A later attempt starts the handler from the beginning and reuses only state that was stored outside the process.

Maintenance keeps durable work moving

Storage preserves state. Maintenance moves deferred and interrupted work forward. It creates runs for due schedules, wakes due retries and waits, recovers expired ownership, finalizes abandoned work, and publishes deferred wakeups.

A durable database can preserve a stuck run perfectly. Before production, give maintenance a clear owner.

Start with the local quickstart, then choose a durable lane.