What is Temporal (durable execution)?
Temporal is a durable-execution platform where you write workflows as ordinary code that survives crashes and resumes exactly where it left off.
Temporal is a durable-execution platform where you write workflows as ordinary code that survives crashes — the engine persists every step's state and deterministically replays the workflow's event history to resume exactly where it left off after a failure. Instead of bolting retry loops, status tables, and cron1 jobs around a fragile script, you write a normal function, and the platform guarantees it runs to completion even if the process running it dies, the machine reboots, or a downstream service is unreachable for hours.
🔗 Learn more — 1 What is cron?
That guarantee is the whole point. A long-running process — an order that takes three days to fulfil, an onboarding flow waiting on a human approval, a payment saga that must compensate if any leg fails — usually drowns in plumbing code that tracks "where are we now." Temporal moves that bookkeeping into the platform.
Workflows versus activities
Temporal code splits into two roles. A workflow is the orchestration logic: the sequence of steps, the branches, the loops, the waits. Workflow code must be deterministic, because the engine replays it. An activity is a single unit of real-world work that can fail or have side effects — an API call, a database write, sending an email. Activities are where non-determinism and I/O live, and Temporal automatically retries them on failure according to a policy you set.
The mental model: the workflow decides what should happen and in what order; activities actually do it. Each activity result is recorded, so when the workflow resumes it already knows the outcome of work that completed before the crash and never repeats it.
Event history and replay
When a workflow runs, Temporal does not snapshot the variables in memory. It appends every meaningful event — activity scheduled, activity completed, timer fired, signal received — to a durable event history. If the worker process dies mid-flight, a new worker picks up the workflow and replays that history through the same deterministic code. Replay reconstructs local variables and the program counter, landing the execution exactly at the line it was on, with all prior activity results already in hand.
This is why workflow code has to be deterministic: replay must produce the same decisions every time. You don't call now() or random() directly inside a workflow — you use Temporal's deterministic equivalents, so the replay matches the original run. Get that right and a workflow can sleep for thirty days, survive a dozen deploys, and still complete correctly.
Retries, timeouts, and signals
Three primitives make this practical. Retries are declarative: an activity that fails is retried with backoff, with no try/except scattered through your code. Timeouts bound everything — how long an activity may run, how long a whole workflow may live — so stuck work surfaces instead of hanging silently. Signals let the outside world push events into a running workflow: a human clicks "approve," a webhook fires, a cancellation arrives, and the workflow reacts mid-execution. Together they cover the awkward middle of distributed systems — partial failure, waiting, and human-in-the-loop steps — without a bespoke state machine.
How this differs from DAG schedulers
It is easy to file Temporal next to Apache Airflow2 or Dagster3, but they solve a different problem. A DAG4 scheduler orchestrates batch data pipelines: it runs tasks on a schedule, models dependencies as a DAG, and is built around moving and transforming datasets — extract this table, then build that one. Temporal orchestrates arbitrary application and business workflows expressed in ordinary code, where the unit of work is a long-lived process with branching logic, not a nightly batch graph.
🔗 Learn more — 2 What is Apache Airflow?
🔗 Learn more — 3 What is Dagster?
🔗 Learn more — 4 What is a DAG (and why orchestrators use them)?
The distinction is the workload, not the quality. For saga-style transactions, multi-step provisioning, or any process that waits on humans or external systems for hours or days, Temporal's durable execution and replay are genuinely powerful and hard to replicate by hand. For plain scheduled batch ETL5 — run a data pipeline6 at 02:00, materialize a few tables — it is overkill, and a DAG scheduler is the simpler, better-fitting tool. The two even compose: Airflow or Dagster can trigger a Temporal workflow when a batch job needs a reliable, stateful sub-process.
🔗 Learn more — 5 What is ETL (and how is ELT different)?
🔗 Learn more — 6 What is a data pipeline?
A practical note: durable execution does not excuse you from making activities idempotency7-safe. Retries and replay mean an activity can be invoked more than once, so each one should tolerate being run again without doubling its effect. Temporal makes the orchestration reliable; the work it calls still has to behave.
🔗 Learn more — 7 What is idempotency (in data pipelines)?