When do you need Temporal? Durable execution vs a normal workflow engine

1. When you need Temporal

Temporal is durable execution infrastructure: you write Workflows and Activities as code, and the server records Workflow Event History so a Worker can replay state after failure and continue from the latest recorded event. Activities may retry, so use it when your process has these properties:

• Long-running. The process spans minutes, hours, days, or months — waiting on humans, external systems, or timers — and must not be lost if a worker restarts.
• Must-not-lose-state. Losing progress mid-way is expensive or dangerous: a half-completed payment, a partially provisioned account, an order stuck between "charged" and "shipped".
• Controlled side effects. Duplicate writes would be expensive or dangerous, so Activity boundaries, retry policies, and idempotency keys must be designed together. Temporal preserves Workflow state, but an Activity may execute more than once during retry.
• Complex compensation / sagas. Failure part-way requires rolling back or compensating earlier steps in a controlled, resumable way.
• Operational ownership. Throughput and SLA requirements shape capacity planning, but do not by themselves establish a need for Temporal; the team must also be willing to operate the service and Workers or use Temporal Cloud.

Canonical fits include payment and billing flows, order fulfillment, infrastructure provisioning, and long-running AI agent pipelines that must survive restarts. Evaluate restart safety, durable state, external waits, recovery, and idempotency boundaries together rather than using a fixed score.

2. When you do NOT need Temporal

Most automation is not this. If your workflows look like the list below, a normal workflow engine may fit without adding durable-execution infrastructure:

• Safe to restart. The whole process can safely be retried from the beginning if it fails.
• Stateless glue. Webhook-to-app, "when X happens do Y", scheduled syncs, notifications, report generation.
• Integration-first. The hard part is connecting SaaS apps, not guaranteeing a multi-day stateful process. That is exactly what visual tools optimise for.
• No dedicated infra owner. Nobody wants to run and tune execution infrastructure or pay for managed durability.

For these, n8n, Zapier, Make, Windmill, or Inngest may fit without requiring the team to own code-first durable-execution infrastructure.

3. What durable execution actually solves

Durable execution makes long-running workflow state recoverable. The engine records events so a Worker can replay the Workflow after failure and continue from the latest recorded state instead of starting the logical process over. That state durability does not make external side effects exactly-once: Activities can be retried and may execute more than once. In practice Temporal replaces or centralises several things you would otherwise hand-roll:

1. Queues + retries. Automatic, configurable retries with backoff become built-in, not custom queue plumbing.
2. Cron + timers. Durable timers let a workflow "sleep" for days and reliably wake up — without a scheduler you have to babysit.
3. Workflow progress tracking. Event History and replay preserve orchestration state, while idempotency keys or equivalent safeguards still protect external writes from duplicate Activity attempts.

The trade is real: you write against an SDK, run workers, and either operate the server or pay for Temporal Cloud. You take on that cost because the guarantees are worth it — not by default.

4. When a normal workflow engine is already enough

A visual or conventional workflow engine is enough when losing and re-running a whole execution is safe. Use these boundary questions rather than a duration or score threshold:

• Can the whole process safely restart from the beginning?
• If a run fails halfway, can you just re-run the entire thing with no harm?
• Is the value mostly in connecting apps rather than guaranteeing a long stateful process?
• Would you rather not run additional infrastructure?

If restart is safe and no workflow state must survive a failure or external wait, a conventional workflow engine is likely enough. If not, evaluate durable execution and the required retry-safe side-effect boundaries.

5. The boundary: Temporal vs n8n vs Windmill vs Inngest

These tools are often lumped together but sit at different layers. This is the map, not a "winner":

Facts (license, deployment, pricing model, statefulness) sourced from the Temporal LICENSE and Temporal pricing (pricing checked 2026-08-29); see the boundary as layers, not a ranking.

Rough rule: Inngest for event-driven durable steps through a managed service, Windmill when the job is turning scripts into workflows and internal UIs, and Temporal when durable Workflow state, recovery, and code-first control are required and the team will own the service or use Temporal Cloud. If the process is really just app-to-app glue, none of them — use n8n.

6. Decision checklist

Run your process through these boundary questions:

• If the process runs longer than a single request and must survive crashes/deploys → lean Temporal.
• If re-running the whole thing on failure would double-charge, double-ship, or corrupt state → lean Temporal.
• If you need durable timers, targeted Activity retries, or saga-style compensation — and can make external writes idempotent → lean Temporal.
• If the work is short, stateless, and safe to retry wholesale → stay on a workflow engine.
• If the value is mainly connecting SaaS apps and nobody will own infra → stay on a workflow engine.

Do not score the answers. If the process can safely restart and does not need durable state, waits, or targeted recovery, a normal engine is likely enough. Otherwise, evaluate Temporal together with the required Activity retry and idempotency boundaries.