Durable Execution overview

This page explains what Durable Execution is in plain words, when to use it instead of Pub/Sub, what the alpha actually ships today, and how it compares to the workflow services on AWS, GCP, and Azure.

What it is

Durable Execution runs workflows: ordinary code whose progress is saved after every step.

That one property changes everything about reliability:

• If a step fails, it retries automatically with backoff — you declare the retry policy once instead of writing retry loops.
• If the machine running your workflow crashes, the workflow resumes exactly where it left off on another worker. Completed steps are never re-run; their saved results are replayed.
• A workflow can safely run for minutes, hours, or days, waiting between steps without holding a process hostage.

Each retryable step is called an activity — for example, one HTTP call to an agent. Your worker is the process that hosts the workflow and activity code; it polls a named task queue for work. The engine underneath is Temporal, a proven open-source workflow runtime, deployed and managed for you with its state in managed Postgres.

The 30-second mental model

You start a workflow by name. The server hands tasks to your worker through the task queue. After every completed activity the result is checkpointed to Postgres. Kill the worker mid-run, start it again, and the workflow picks up at the next step.

When to use it

Reach for Durable Execution when a job is multi-step and must finish despite failures:

• Call an agent, then call it again with context from the first answer (the shipped sample does exactly this — see Run a workflow).
• Pipelines where step 3 must not re-run step 1's side effects after a crash.
• Anything you would otherwise build from cron jobs, retry loops, and a status table.

Use Pub/Sub instead when you just need to hand a message from one service to another. Rule of thumb: Pub/Sub moves events between services; Durable Execution coordinates steps within one process that has to complete.

What the alpha ships (honest scope)

Sample integration only

Durable Execution is the platform's most alpha service. Today it is a managed Temporal deployment plus one sample worker — not a managed workflow product:

• No REST API, no platformctl command, no console page. The console shows only a capability card with a link to help.
• The Temporal frontend is in-cluster only (temporal-frontend.cai-services.svc.cluster.local:7233, gRPC). There is no externally reachable endpoint, so your worker must run inside the cluster.
• No platform authentication on the Temporal frontend and a single shared Temporal namespace — no per-project isolation. Network reachability is the only boundary.
• Temporal's server components run 3 replicas each (the web UI runs 2), but their state lives in a single-instance managed Postgres cluster — that database, not the Temporal pods, is the single point of failure.
• You operate it with kubectl and the temporal CLI, not with platform tooling.

If that scope works for you, it is real Temporal — retries, checkpoints, and full workflow history all work today.

How it compares

If you know...	Ours is...	Honest differences
AWS Step Functions	The same orchestration job, but workflows are real code (the sample is Go) instead of JSON state machines. A "Task state" is an activity; retries come from a policy, not hand-written Retry blocks.	Step Functions has a visual designer, 220+ service integrations, SLAs, and a managed API. We have a sample worker and the temporal CLI.
GCP Workflows	Code instead of YAML — branching and loops are if and for, not a DSL.	GCP Workflows is serverless with per-step pricing and console tooling; ours requires you to run a worker in-cluster.
Azure Durable Functions	The closest cousin: code-first orchestrations with checkpoint-and-replay, like an orchestrator function calling activity functions.	Durable Functions makes you pick a storage backend before "hello world"; here the backend (Temporal + Postgres) is already provisioned. But Azure has console monitoring, bindings, and scale-out; we don't yet.

One honest advantage over all three: no billing meter. This runs on your own cluster — a workflow that sleeps for a day costs you nothing extra.

Where to go next

• Run a workflow — deploy the agent-pipeline sample, start it, and watch it complete.
• Durable agent pipeline tutorial — the longer guided version.
• Invoke an agent — the endpoint the sample workflow calls as its activities.